Squeeze every drop of performance out of your IIS 5.0 or IIS 4.0 system
Web server configurations depend on multiple factors such as CPU speed, number of CPUs, amount of memory and disk space, type of network cards, and hardware manufacturers. If you choose unwisely regarding any of these components, the server's performance will most likely be subpar. The most important and most talked about item on the list is memory. Let's dig into the subject of how much memory an IIS system needs, how IIS uses memory, and how you can tweak IIS to make it use memory more efficiently. The following discussion applies to both IIS 5.0 and IIS 4.0.
How Much Is Enough?
When the topic of memory comes up, the first question usually is, "How much is enough?" A basic IIS implementation serving static Web pages to a few users might require no memory beyond what Windows 2000 or Windows NT 4.0 requires. An IIS system serving active content to thousands of users will probably require quite a bit more memory. I can't give you one answer to the "How much is enough?" question, but I can give you some insight into how IIS uses memory.
In early 2000, CN2 Technology tested an IIS 5.0 application in four scenarios: using low-level Internet Server API (ISAPI) code, using C++ COM components, using Visual Basic (VB) COM components, and using Active Server Pages (ASP) script with no custom components. The ISAPI files, COM components, and ASP script ran on Win2K Advanced Server with Network Load Balancing (NLB). The database ran on a separate server. You can see a description of the test application that CN2 Technology used at http://msdn.microsoft.com/library/backgrnd/html/nilewp.htm.
In CN2 Technology's tests, the IIS 5.0 servers were insensitive to the amount of memory in the system. During the first set of tests, each IIS server in the NLB cluster had 256MB of memory. Then, CN2 Technology took the servers down to 128MB and reran the tests. The tests showed little performance degradation. Of course, these servers were running only one application. A server running two or more applications will place more, or at least different, memory demands on the system. Also, the servers were running in an NLB cluster, so each server was supporting fewer users than if only one server had been used. You might conclude from the CN2 Technology tests that if your servers are running only IIS 5.0 and COM+ components, they might not need more than 256MB of memory, at least to begin with.
What does IIS use that memory for? IIS 5.0 and IIS 4.0 both use the Inetinfo process as the main IIS process. The Microsoft Internet Information Services 5.0 Resource Guide mentions that Inetinfo consumes about 2.5MB of memory when all services are running. IIS 4.0 Inetinfo consumes about 2MB of memory. Of course, these numbers assume the default IIS settings and that no ASP code is running and no other activities are going on.
According to the IIS 5.0 resource guide, each connection to IIS 5.0 uses about 10KB of memory, and the same is likely true for IIS 4.0. Thus, 500 connections would add 5MB and 1000 connections would add 10MB to the amount of memory used. When you think about the number of connections you have, remember that one user usually has multiple connections. For example, 1000 simultaneous users will usually translate into more than 1000 connections.
In addition, IIS increases the size of the Inetinfo process for various reasons, such as log files. If you turn on logging for a Web site, IIS maps a chunk of memory (in 64KB blocks) as the site's log file. A memory-mapped log file provides fast access to the file system. However, if, for example, you enable logging for each of the 10 Web sites on your server, IIS is setting aside quite a bit of memory for log files.
IIS also increases the size of the Inetinfo process to accommodate applications running in that process. You can run IIS 5.0 and IIS 4.0 applications in the Inetinfo process or out of the process. Applications that run in process typically perform better than those that run out of process, but if an application running in process crashes, it can take IIS down with it.
In IIS 4.0, each application that runs out of process runs in its own Mtx process. In IIS 5.0, each application that runs out of process runs in its own Dllhost process. IIS 5.0 has an additional processing option: Multiple applications can run together in a pooled Dllhost process. According to Microsoft, pooled applications perform better than out-of-process applications but not as well as in-process applications. By default, IIS 4.0 applications run in process and IIS 5.0 applications run out of process. For more information about IIS 5.0's three process options, see my Windows 2000 Magazine article "IIS 5.0 Opens the Throttle" (Winter 2000).
You can use Windows Task Manager to discover how much memory Inetinfo and Dllhost or Mtx are using. Figure 1 shows two Dllhost processes (i.e., dllhost.exe) running on an IIS 5.0 system. The first Dllhost entry is an out-of-process application. The second Dllhost process is the pooled process on the server and represents the entire pool's memory usage: 7972KB. You can also see that the Inetinfo process on this system is using 14,236KB of memory.
I know of several sites that have experienced a memory problem when running applications out of process in IIS 4.0. The symptoms are clear: The application gradually slows down to the point at which it's unusable. Rebooting the NT 4.0 server solves the problem for a while, but then the application slows down again. IIS 4.0 application slowdowns are a result of poorly coded applications or problems with IIS 4.0. Apply application and OS fixes and service packs, and where possible, change out of process IIS 4.0 applications to run in process. I'm not aware of similar slowdowns with out of process or pooled applications in IIS 5.0, although as I pointed out earlier, Microsoft says applications will run faster in process.
To answer the question of how much memory is enough for your IIS server, be prepared for some ongoing trial and error. Each server (or set of servers in a farm) has a different set of applications and a different configuration. Thus, each server will require a different amount of memory. You can start with a known amount such as 128MB or 256MB, then test your servers to find out how much to add. You must also monitor the servers over time to keep up with changes to their configuration, the applications running on them, and their load.
IIS and Server Properties That Affect Memory
Before you add memory to an IIS server to alleviate a performance problem, you should make sure a few key configuration options are set properly for your situation. The script-engine cache, which contains ready-to-run script engines, consumes a small amount of memory. When IIS receives a request for an .asp file, it can access a script engine from the cache rather than starting one from disk. This results in much faster performance for .asp files. IIS 5.0 and IIS 4.0 default to 30 cached script engines. You can change this property as needed on the Process Options tab, which Figure 2 shows. To access this tab in IIS 5.0, open Internet Services Manager (ISM), select WWW Service, click Edit, and click Home Directory. In the Application Settings section, click Configuration, and click the Process Options tab.
Another memory user is the IIS script-file cache, which holds templates (compiled .asp files with all their included files). When IIS receives a request for an .asp file, it looks first in the script-file cache. If the file isn't in the cache, IIS reads the file from disk, processes the file, and places it in the cache. The time to process and cache a file ranges from much less than 1 second to many seconds, depending on the length of the script and how busy IIS is when it receives the request. IIS can take as long as 20 seconds to load large .asp files from disk (a large .asp file with 8 to 10 included files can have 3000 or more lines of code), whereas IIS could load those files from the cache in less than 1 second.
If you don't correctly size the script-file cache property, your application performance will suffer. IIS 4.0 is set to cache all .asp files by default, which lets the cache grow arbitrarily large and potentially use all of a server's memory as cache. IIS 5.0 defaults the cache to 256 files to prevent excessive growth. For both IIS 5.0 and IIS 4.0, you can use the Process Options property page that Figure 2 shows to change the maximum number of .asp files to be cached.
Derek Hoskins October 28, 2003