Tuning Your iPlanet Web Server
November 19, 2001

by Don MacVittie

Your Web server's performance is an important part of users' overall experience on your site -- possibly the most important part. This article focuses on tuning the iPlanet Web Server using the tools available out of the box. You'll walk through some simple optimizations that are configurable within the server.

A Note About Hardware

All of the optimizations suggested here have hardware implications. To avoid getting frustrated, make sure your hardware is able to handle the volume of connections you are setting up. For more information about general hardware and OS tuning issues, see Optimizing Your Web Server.

How to Modify Settings

Most of the settings discussed can be modified in the magnus.conf file located in [server_root]/[server_id]/config/magnus.conf where [server_root] is the directory you told the installation program to place your iPlanet Web Server in, and [server_id] is the directory named after the server you are trying to modify.

All of these settings can be modified through the Server Manager interface in the "preferences" tab. For sockets, choose "edit sockets" from the preferences tab. For all other settings, choose "Magnus Editor" and select "Manage" from the list.

Threads and Sockets

The number of threads available for HTTP processing and the behavior of those threads can have a significant impact on your server's performance. Likewise, the number and behavior of sockets that are configured to accept incoming connections are important to your users' ability to get to your Web site and the quality of their experience.

Threads
Each thread handles one request at a time, meaning it creates a practical limit on the number of simultaneous connections that can be serviced by your Web server. This number is adjustable to meet your environment's needs. Since each idle thread uses unnecessary resources, you should monitor the results with a tool such as perfdump to ensure you're not overloading your server with idle threads.

There isn't a one-to-one relationship between threads and requests. This is because the thread will handle a request in a few microseconds and then move on to the next request (if one is waiting). You may need to play with the number of threads so you have enough at peak usage and not too many idle at low usage.

There are two settings that affect the number of threads residing on your system at any time -- both of which are stored in magnus.conf and can be modified either directly in magnus.conf or through the Server Manager dialogs:

• RqThrottleMinPerSocket is the minimum number of threads to keep around when the server is idle. According to the iPlanet Web Server documentation, the default value for this setting is 48.
  
  
• RqThrottle is the maximum number of threads to create. Once this limit is hit, incoming requests are put in a "waiting queue" and held there until they time out or a thread becomes available to service them. This setting's default value is identified on the iPlanet for Developers Web site as both 512 and 128. For 4.0 and earlier versions, use 128; use 512 for 5.0 and later versions.
  
  
• ThreadIncrement determines the number of threads to start up when all threads are busy. The default is 10.
  
  
• MaxProcs is the maximum number of processes available on the server. Threads are restricted to running inside a process, so if you have multiple processors and want to make the best use of them, set MaxProcs to be the number of processors on your system. This way one process with the correct number of threads is started per CPU. This setting can rapidly overtake your network connection if you have servers with many CPUS, so watch network volume when adjusting MaxProcs. The default value is 1.
  
  
• IOTimeout is the amount of time the server waits for the client to send data. Since dial-up connections are inherently slow, setting this value too low will result in dial-up users losing connections while other users have no problems. Setting IOTimeout too high will slow your server down, forcing it to wait for more information from a client that may have closed or a user who clicked away from your site. The default value of 30 seconds is high unless you have a large contingent of dial-up customers. If you are serving an intranet where all customers are on high-speed connections, 30 seconds is a huge waste of resources. Set IOTimeout to 10 and see if machines are getting disconnected -- this isn't likely to happen in a modern LAN environment.
  
  

Connection Persistence

A persistent connection is one the server keeps open between requests from the client. The settings that affect connection persistence allow you to determine the number of connections kept around, how long persistence lasts, and how many connections can be backed up while waiting for connections to open. Performance is impacted because it is expensive to build new connections each time a user clicks from one page on your site to another. Persistent connections keep track of who's visiting your site and allow them to move within your site without rebuilding the connection information each time:

• ListenQ determines the number of waiting connections the server can hold onto while it frees up connection threads. If this setting is too low, your users will get "connection refused" errors. If it is too high, your users will wait and eventually get "connection timed out" errors. The default is operating system-specific (4096 for AIX, 200 for Windows NT, and 128 for all other operating systems). This makes sense given the sockets doing the listening are at the operating system or driver level. Do not play with this setting too much. If your connections are rejected, this is an indication of a bottleneck elsewhere in your system -- check the other settings before raising or lowering the default value. If you must modify the value, make it as small as possible without rejecting connections.
  
  
• KeepAliveThreads is the number of threads that "keep connections alive" simultaneously. Connections that are kept alive get faster responses from your server, but the mechanism for keeping them alive costs system resources. The documentation for the iPlanet Web Server recommends keeping this setting as a small multiple of the number of CPUs on your system. This sounds reasonable since the overhead of keeping those connections alive would be related to CPU and memory. The default is 1 -- change it to two times the number of CPUs in your system.
  
  
• KeepAliveTimeOut is the amount of time between the last request from a client and the point at which the server closes the connection. This does not mean the user can't get to the server, only that connection-relevant information is lost, and the client must negotiate a new connection with your server. The default value is 30 seconds for regular systems and 300 seconds for encrypted systems. Avoid changing this value too much. If all your users are dial-up customers, you might need to increase the setting. If you're serving an intranet on a 100-megabit or higher-speed network, you'll probably want to decrease the setting. Be aware that a connection kept alive is significantly faster than one that is not kept alive, but if a user leaves your site, KeepAliveTimeOut is the amount of time that elapses before the connection is available to another user.
  
  
• MaxKeepAliveConnections is the maximum number of connections to keep alive at once. Each connection kept alive holds one connection out of the connection pool to service incoming requests, but speeds the access of the user whose connection is kept alive. The default is 256. This number should be coordinated with KeepAliveThreads and RqThrottle, and should not be too big as a percentage of RqThrottle. Setting this value to one half of the RqThrottle should be enough for most servers.
  
  
• ConnQSize is the size of the queue for holding incoming connections that are not being serviced yet. The default is 5000. The documentation recommends this value always be bigger than the maximum number of file handles your Web server can have open. Since processing of requests is so fast, keep this number high, and raise it if you increase the number of processors on the machine. When there are 512 threads serving requests on your server, if each request takes an average of 20 milliseconds to process, 5000 is actually a little low. Calculate the maximum amount of time you're willing to let users sit and wait, then divide that number by 30 milliseconds (more if your server is slow or you're doing a lot of dynamic content), then divide it by the number of threads servicing requests. This should give you a good ballpark number with which to start tuning. Remember to always err on the side of this number being too small. If the value is too large, your users will sit -- and likely get frustrated -- until they time out.
  
  

Caching Settings

There are two separate caches on the iPlanet Web Server. The settings on these caches can dramatically impact your users' ability to access your Web site:

• EnableFileCache turns caching on and off. If you are using images (such as a company logo) on many pages, or if you have pages that are accessed frequently, file caching is one of the best ways to improve performance. The default is set to "on" -- leave it that way.
  
  
• TransmitFile copies the file to a temporary directory. If this copying allows files with the same name but different paths to be reused, it is a major improvement in file caching. If this setting copies the files and makes several copies -- if there are multiple copies of same-named files in your directory structure -- then it should be turned off.
  
  

Content Considerations

Because dynamic content must be "built" at request time, it is normally slower than static content on any server. Since CGI is a big system drain, the next set of optimizations is designed for it specifically. If you make extensive use of CGI, normal caching and many of the options discussed in this article will not be very useful. The reason is that CGI is somewhat "outside" the control of the Web server. Optimizations for CGI have traditionally been the job of the CGI developer:

• MaxCGIStubs controls the maximum number of executing CGI processes that can be executed at one time. It limits the amount of server resources being consumed by CGI at any one time. Setting the value too high in a CGI-intensive environment may cause response degradation. The default value is 10. If you have long-running CGIs, you might want to set this value higher.
  
  
• MinCGIStubs is the minimum number of processes to reserve for use by CGI. The default is 2. The documentation states that if you have init-cgi specified in the magnus.conf file, then this default will be started on server start-up. If you're not using CGI, set the value to "0" just to be safe. Ensure there is an init-cgi statement in the initialization section of magnus.conf.
  
  
• CGIExpirationTimeout helps you catch runaway CGI scripts and kill them automatically. The default is 300 seconds. Most users will not wait around 300 seconds, so get a decent timing of the CGI scripts running on your system and use that as your guide to set this value.
  
  
• CGIStubIdleTimeout refers to how long after a CGI stub process was last used to launch a CGI program before the system shut down the stub process. It is a good idea to keep this value near the default of 30 seconds. Since the Web server will not shut down stubs once the number is less than or equal to MinCGIStubs, you're assured of having that many stubs around for use. Because the stubs themselves use resources the rest of your server could use, you don't want them around and idle for too long, but you don't want to destroy a stub only to create a new one microseconds later. This setting is really important in CGI-intensive environments, and in those environments 30 seconds between uses of a CGI stub is a long time.
  
  

Log Settings

Logging of user requests and analysis of those logs can give you a lot of good information about your user base and the most viewed pages of your site. The problem is that logging is an expensive proposition. The iPlanet Web Server provides some options to minimize the cost of logging. Here are some of the more useful ones:

• DNS Lookups slow your Web server while they query DNS for each client that requests access. The only use of this setting is to write log file entries by name instead of by IP. Turn this option off if you have performance issues or if you have DNS Caching turned off.
  
  
• DNS Caching keeps DNS requests and responses cached. Since DNS Lookups are expensive -- more so if the DNS server resides on a remote machine -- using this feature is a good idea. Turn this setting on if you turn on DNS Lookups; without them, it is not useful. Even with DNS Caching, your average Internet site will be significantly slower than with DNS turned off.
  
  
• LogFlushInterval determines how frequently the log writes ("flushes") the accumulated log entries to disk. The default is 30 seconds. Writing to disk is expensive in terms of response time, so keep this number at 30 seconds or higher. If your server crashes, you will lose all log entries since the last flush. So don't set this value too high, or you will lose information if something goes wrong.
  
  
• LogVerbose causes the iPlanet Web Server to log all sorts of messages that aren't normally logged when this value is set to "on." This is a great debugging tool. Just remember to turn it off when you're done! The default is "off."
  
  
• LogVsId causes the log files to include the virtual server ID in each line when this directive is set to "on." This is useful if you have to do per-virtual-server log analysis, but it costs time each instance the log file is written to. Turn this directive off unless business needs require the use of virtual server log analysis.