Feiten en mythen over sessies
Door Charles Carroll
29 mei 2000
Er zijn nogal wat misverstanden rond sessie data. Sessies zelf zijn een subtiel en complex
onderwerp, maar is aanzienlijk verward doordat mensen slechte informatie hebben verzameld
van code die anderen hebben gemaakt, die sessies verkeerd gebruiken. Dit komt ook omdat de
gegevens over de prestaties misleidend zijn als een site klein is, of als er alleen getest
wordt met simpele stress tests, die niet alle snelheidsfactoren tonen. We zullen alles nu
verduidelijken.
Een aantal analogieën kunnen helpen. Een Porsche lijkt heel snel om overal te komen
(er vanuit gaande dat je 2 passagiers hebt) totdat je 3-10 passagiers hebt. Dan zal een busje
sneller zijn, omdat je minder ritten hoeft te maken. In client-server termen "schaalt" de
Porsche niet goed voor meer dan 2 passagiers. Aan de andere kant: als een groep van 100 mensen
van Washington, D.C. naar New York wil voor het weekend raden we een touringcar aan. Echter als
iemand een touringcar neemt om naar de supermarkt te gaan, is het wel duidelijk dat dit niet zo
snel gaat als met een Porsche.
Feit #1: De sessie eindigt NIET als een browser window sluit.
Feit #2:
<%Session.Abandon%>
commando kan een sessie eindigen.
Feit #3: een andere manier waarop een sessie eindigt, is als een gebruiker geen enkele
pagina bezoekt binnen die site/applicatie binnen X minuten. Standaard is dit 20 minuten.
Het volgende script laat zien wat deze instelling is op je server:
<html>
<body>
<%
Response.Write "Session Timeout=" & Session.Timeout & "minuten <br>"
%>
</body>
</html>
Feit #4: Er is geen garantie dat sessie IDs anders zijn elke keer als er een nieuwe
sessie wordt gegenereerd. Als er 1,000 sessies zijn, zullen er 1,000 unieke sessie IDs zijn.
Maar als voor 200 mensen de sessie verloopt (als gevolg van een timeout of expliciet .Abandon)
en er beginnen 150 nieuwe sessie dan kan en zal ASP dezelfde sessie IDs gebruiken die eerder
gebruikt werden.
Mythe #1: het opslaan van grote objecten (recordsets, database data, objecten), die
gebruikers openen, in sessies bespaart geheugen*. Nee. Nee. Nee. Aangezien sessies starten als
gebruikers een pagina openen en niet eindigen tot 20 minuten nadat zij de laatste pagina hebben
geopend. Denk er eens over na. Als 200 nieuwe bezoekers per minuut gedurende 5 minuten jouw
site bezoeken zijn dat 1,000 sessies en ongeveer 1000 x het gebruikte geheugen voor sessie
variabelen. Als 500 mensen de site verlaten, heb je nog 1000 sessies en 500 gebruikers
(er wordt 2x zoveel geheugen gebruikt als nodig is) totdat de server 20 minuten geen activiteit
van die 500 gebruikers, die niet op de site zijn, bemerkt. Applicatie variabelen (niet sessie
variabelen) kunnen op deze manier gebruikt worden zonder dat het geheugen verspilt. Ze kunnen
gebruikt worden om gegevens op te slaan die in meerdere scripts op de site nodig zijn of zelfs
HTML die gegenereerd is vanuit een database cachen zoals in The Worlds Fastest Listbox.
Voor voorbeeld zie:
http://www.learnasp.com/learn/speedappdata.asp.
Mythe #2: Het opslaan van grote objecten (recordsets, database data, objecten), die
gebruikers openen, in sessies versnelt de toegang. Nee. Nee. Nee. Objecten in sessies hebben
verschillende potentiële snelheidsbarrières afhankelijk van hun geheugenmodel.
-
Thread local storage wordt in sommige objecten intern gebruikt (met name Visual
Basic componenten). Dit betekent dat zodra je zo’n component toewijst aan een sessie
variabele behorende bij een gebruiker, dan moeten alle verzoeken van die gebruiker
afgehandeld worden door de :thread" waaronder het component gemaakt is. Als ze bijvoorbeeld
aan hun sessie start thread #3 toegewezen hebben gekregen als ze veel pagina’s op de site
openen, dan zal alle activiteit onder thread #3 afgehandeld worden. Dit fenomeen geef ik
de bijnaam Thread Locking.
-
Free-threaded objecten hebben geen snelheidsbarrières (hoewel zoals Mythe #1
stelt, zal je altijd teveel in geheugen hebben als je objecten opslaat als sessie variabelen).
-
Apartment-Threaded objecten, met name Visual Basic componenten en het Microsoft Access
database stuurprogramma, die Single-Threaded apartments (STA) zijn, hebben een aantal grenzen
aan hun performance. Simpel gezegd, alle gebruikers verzoeken aan een STA zijn geserialiseerd.
Uitleg van serialisering
Als 100 gebruikers de site binnenkomen, zal hun gebruik van
die code op volgorde gebeuren. Als al de gebruikers 10-20 records uit een database ophalen, zal
je waarschijnlijk geen effect merken. Maar als persoon nummer 3 2,000 records ophaalt, dan zal
persoon nummer 4, die 2 records wil ophalen, moeten wachten totdat persoon nummer 3 zijn 2,000
records heeft opgehaald. AU!!!!! Persoon nummer 4 zal denken dat de webserver erg langzaam is
terwijl er slechts 2 records worden opgehaald.
Uitleg van Free-Threading
Uitvoering van gebruikersverzoeken is "round-robin"
(de verzoeken worden ombeurten voor een deel uitgevoerd) als
de webserver niet elk gebruikersverzoek hoeft af te ronden voordat het overgaat naar een andere
gebruiker. De code kan overgaan naar gebruiker 4 en zijn records pakken, vervolgens die van
gebruiker 5 en later pas gebruiker 3 zijn grote verzoek eindigen.
Uitleg van Threads
Je web server maakt threads (4 per CPU is de default in IIS4;
het zou moeten worden aangepast naar 20, zie
http://www.learnasp.com/learn/speedserver.asp).
Als je webserver bijvoorbeeld 4 threads heeft, dan zouden 1000 gebruikers 250 per thread kunnen
zijn of 700 op één thread en elk 100 op de andere threads. Het laatste is een ernstige onbalans
aangezien één thread overwerkt is (en dus langzamer) terwijl de anderen te weinig te doen hebben.
© Charles Carroll
(vertaling copyright ASPNL)
|
