My site depends heavily on Secure Sockets Layer (SSL). I am trying to determine resource requirements and am wondering how long an SSL session is maintained once created. If I navigate away from a secure page and then back right away, the session resumes. How long does this session stay valid when not in use?
Although SSL is very useful, it's an expensive operation from the viewpoint of server resources. I recommend using SSL only when necessary, which varies from not at all for casual Web sites to always for stockbroker Web sites. So, planning for how much load SSL places on your server is important in high-volume sites.
The amount of time an SSL session stays open is important. You want to release server resources as soon as you can, but if you release them too quickly, you'll need to rebuild the SSL session, which increases the burden on the server. Microsoft changed the default timeout for the SSL session cache from 2 minutes in Windows NT 4.0 to 5 minutes in Windows 2000. If you expect extended SSL sessions, I recommend increasing the SSL session timeout, which the ServerCacheTime registry entry controls. (If you enable HTTP 1.1 KeepAlives, the server ignores the timeout parameter and doesn't terminate a session until the browser explicitly closes the connection or the TCP/IP session times out. KeepAlives are enabled by default.)
This registry entry isn't present by default. To add the registry entry, you need to create the ServerCacheTime REG_DWORD value in the HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL registry subkey. (Always back up your metabase before making changes to it.) After you've created the value, set the data field to the number of milliseconds (ms) you want for the timeout. (The default value of 5 minutes in Internet Information Services—IIS—5.0 is 300,000ms.) You can find details about this and other useful IIS 5.0 tuning tips and tricks at http://www.microsoft.com/technet/iis/iis5tune.asp.
I run an application on Internet Information Server (IIS) 4.0 that uses the Session_onEnd event to trigger cleanup for the application. I've discovered that the event doesn't always fire when a session ends. Some articles and newsgroups state that this problem is a known bug. I can't find any such reference, but clearly Session_onEnd isn't working as expected in IIS 4.0. My tests with Internet Information Services (IIS) 5.0 show that Microsoft has apparently fixed the problem. Can you shed some light on this bug in IIS 4.0?
The problem isn't a bug. Rather, it boils down to a COM threading problem. The answer to your question requires an understanding of how COM components work with various threading models. Details about this important subject are beyond the scope of this answer, but IIS administrators should have a keen interest in this topic for several reasons. The chief concern is that COM objects that your system uses (including Microsoft-provided COM objects) can dramatically affect performance and scalability.
When you create a COM object, it's assigned a threading model. Three threading models exist:
- Apartment threading—Only one thread from an object can communicate with the server. You can, however, have multiple instances of the object, each with its own thread. This threading model is the only one that the Microsoft Access database engine supports, which is the primary reason Microsoft recommends Microsoft SQL Server as the database of choice with IIS.
- Free threading—An object can use (spawn) multiple threads.
- Both threading—An object can be accessed as an Apartment-threaded object or Free-threaded object.
You asked why Session_onEnd doesn't appear to fire in IIS 4.0 but seems to work in IIS 5.0. By default, ADO is marked as Apartment threaded in the registry, which means that one thread is at work for a database access request. In this mode, the thread that creates the ADO object is the same thread that must destroy the ADO object. Let's say that a user makes a query to a database and that database isn't available for 15 minutes. Tired of waiting, the user leaves the page and goes back to downloading .mp3 files or whatever he or she was up to. The user session is over, but the thread that must destroy the session isn't available because it's still waiting on the database. Session_onEnd actually fires, but a thread can't destroy the ADO object because the only thread that can do the job is busy. This delay gives the appearance that Session_OnEnd never fired.
This same sequence of events can occur if you try to use Active Server Pages (ASP)intrinsic objects in Session_onEnd. You can't, for example, use the Response object to send information to the browser because the session is closed. This fact might seem obvious to some, but it eludes more programmers than you might think.
So, how did Microsoft improve this functionality in IIS 5.0? IIS 4.0 trusts the registry setting that says ADO is Apartment threaded, but IIS 5.0 doesn't. Instead, IIS 5.0 queries the component to get its threading model. ADO is really Both threaded, so IIS 5.0 can create the ADO object on one thread, then use another thread to destroy the ADO object. This ability makes the Session_onEnd event appear fixed in IIS 5.0.
You can reconfigure ADO so that it's marked as Both threaded on Windows NT 4.0 by modifying the registry. (Always use extreme caution when editing the registry.) Microsoft provides a file to assist with this reconfiguration. To reconfigure ADO, follow these steps:
- Locate the file adofre15.reg. (If you accepted the defaults for program file location when you installed IIS, adofre15.reg will be in C:\program files\common files\system\ado.)
- Make the directory containing the file your current directory, and issue the regedit adofre15.reg command. Reboot the server.
- If you make the above change and decide to return to the Apartment-threaded model, repeat the above process with the adoapt15.reg command.