|
Session Overview & Myths by
Charles Carroll
Session data is greatly
misunderstood. Sessions themselves were a subtle and complex issue, but the
subject was confused considerably by bad information people gathered from code
others made that misused sessions. It is also confused by anecdotal performance
evidence when a site is small, or the testing is only done within simple stress
tests that don't reveal all the speed issues. We will clarify it all now.
A couple analogies may help. A
Porsche seems really fast to get anywhere (of course we assume you have 2
passengers) until you have 3-10 passengers. Then a mini-van will beat it because
you have less trips to make. In client-server terms the Porsche doesn't SCALE
WELL for more than 2 passengers. On the other hand, when a group of 100 wants to
go to Atlantic city for the weekend we recommend a Tour Bus. However, someone
taking a Tour Bus to the grocery store has anecdotal evidence it is not as fast
as a Porsche.
Fact #1: When a browser
window closes, the session DOES NOT end.
Fact #2: <%session.abandon%>
command can end a session.
Fact #3: Another way a
session ends is when a user has not visited any page within that
site/application with ___ minutes. The default is 20 minutes of
inactivity. The following script can show what the settings are on your server:
filename=/learn/test/sessionsettings.asp
<html><head>
<TITLE>sessionsettings.asp</TITLE>
</head>
<body bgcolor="#FFFFFF">
<%
response.write "Session Timeout=" & session.timeout & "minutes <br>"
%>
</body></html>
Fact #4: Session ids are not
guaranteed to be different anytime a new session is generated. If there are
1,000 sessions there will be 1,000 unique session ids. But if 200 people loose
session (due to timeout or explicit .abandon) and 150 new sessions are begun ASP
may and will certainly use the same session IDs it was using earlier.
Myth #1: Storing large
objects (recordsets, database data, objects) users access in sessions saves
memory*.
No. No. No. Since sessions start
when users access one page and don't end until 20 minute after they access the
last page. Think about it. If 200 news persons a minute hit your site for 5
minutes that is 1,000 sessions and appropriately 1000 x the memory consumed for
session variables. If 500 people go away, you still have 1000 sessions and 500
users (twice as much memory is consumed as needed) until the server detects 20
minutes of inactivity for those 500 users who are not on the site.
Application variables (not
session variables) can be used this way without wasting memory. They could be to store variables most scripts on a
site needed to access or even HTML cached from databases like in The Worlds Fastest Listbox Example @
http://www.learnasp.com/freebook/asp/speedappdata.aspx
Myth #2: Storing large
objects (recordsets, database data, objects) users access in sessions speeds up
access.
No. No. No. Objects in sessions have
several potential speed barriers depending on their memory model.
-
Thread local storage is
used internally in some objects (notably VB components). This means once you
assign such a component to a session variable attached to that user all user
request must remain on the thread they started on. If they for example were
assigned Thread #3 upon their session start as they access many pages at the
site all their activity will remain on thread #3. I nickname this phenomena Thread
Locking.
-
Free-threaded objects
have no speed barriers (though as Myth #1 states, you will always have too
many in memory if you store objects as session variables).
-
Apartment-Threaded objects,
notably VB components and the Microsoft Access databas driver which are Single-Threaded
apartments (STA) have some performance limits. Simply put, every user
request to a STA object must be serialized.
Serialization explained: If 100 users hit the site
their use of that code is in sequence. If all the users retrieves 10-20 records
from a database you might notice no effect. But if person 3 retrieves 2,000
records, person 4 retrieving 2 records will occur after the person 3 retrieves
2,000 records. OUCH!!!!! Person 4 will think the webserver is very slow only
retrieving 2 records.
Free-Threading explained: Users execution is more
round-robin like where the webserver does not have to finish each users request
before moving to another user. The code may be able to move to User 4 and grab
their records and then person 5 and later finish person 3's large request.
Threads explained: Your web server spawns threads
(4 per CPU is the default in IIS4; it should be adjusted to 20 see http://www.learnasp.com/freebook/asp/speedserver.aspx.
If your webserver had for example 4 threads, then 1000 users might be 250 per
thread or 700 on one thread and 100 each on the other threads. The latter is a
severe imbalance as one thread is overworked (thus slower) while other threads
are underworked.
 |  |  |
|
There are many worthy charities!!. But perhaps help starving children in Africa or South America AND help Charles too.
a $5 tip buys him lunch at McDonalds,
a $20 tip buys his kid Hitoshi a new computer game,
a $39 tip buys his daughter Michiko a few nice outfits.
See our donor list.
| |
 | |  |
|
|
|
|