Complete Contents |
About This Guide
Chapter 1 Introduction to iPlanet Web Server
Chapter 2 Administrating iPlanet Web Servers
Chapter 3 Setting Administration Preferences
Chapter 4 Managing Users and Groups
Chapter 5 Working with Server Security
Chapter 6 Managing Server Clusters
Chapter 7 Configuring Server Preferences
Chapter 8 Understanding Log Files
Chapter 9 Using SNMP to Monitor Servers
Chapter 10 Configuring the Server for Performance
Chapter 11 Extending Your Server with Programs
Chapter 12 Working with Configuration Styles
Chapter 13 Managing Server Content
Chapter 14 Controlling Access to Your Server
Chapter 15 Configuring Web Publishing
Chapter 16 Using Search
Appendix A HyperText Transfer Protocol
Appendix B ACL File Syntax
Appendix C Internationalized iPlanet Web Server
Appendix D Server Extensions for Microsoft FrontPage
Appendix E iPlanet Web Server User Interface
Configuring the Server for
This chapter is intended for advanced administrators only. Be cautious when you tune your server. Do not change any values except in exceptional circumstances. Read this chapter and other relevant server documentation before making any changes. Always backup your configuration files first.
This chapter is intended for advanced administrators only. Be cautious when you tune your server. Do not change any values except in exceptional circumstances. Read this chapter and other relevant server documentation before making any changes. Always backup your configuration files first.This chapter includes the following sections:
|About Server Performance|
Web servers have become increasingly important for both internal and external business communications. As web servers become more and more business-critical, server performance takes on added significance. The iPlanet Web Server, Enterprise Edition continues to lead in this area, by setting a new standard for performance.
iPlanet Web Server was designed to meet the needs of the most demanding, high traffic sites in the world. It flexibly runs on both Unix/Linux and Windows NT and can serve both static and dynamically generated content. iPlanet Web Server can also run in SSL mode, enabling the secure transfer of information.
Because iPlanet Web Server is such a flexible tool for publishing, customer needs vary significantly. This document guides you through the process of defining your server workload and sizing a system to meet your performance needs. This document addresses miscellaneous configuration and Unix/Linux platform-specific issues. It also describes the perfdump performance utility and tuning parameters that are built into the server. The document concludes with sizing information.
The first step toward sizing your server is to determine your requirements. Performance means different things to users and to webmasters. Users want fast response times (typically less than 100 ms), high availability (no "connection refused" messages), and as much interface control as possible. Webmasters and system administrators, on the other hand, want to see high connection rates, high data throughput, and uptime approaching 100%. You need to define what performance means for your particular situation. Here are some areas to consider:
Encrypting your iPlanet Web Server's data streams with SSL makes an enormous difference to your site's credibility for electronic commerce and other security-conscious applications, but it also can seriously impact your CPU's performance. Note that SSL always has a significant impact on throughput, so minimize your use of SSL for best performance. Also, multiple CPUs help SSL, so consider buying a multi-CPU server if you need to use SSL.
To monitor the performance of your server, use the following tools: These tools are explained in more detail in the following sections of this document.
|The perfdump Utility|
The perfdump utility is a service function built into iPlanet Web Server that collects various pieces of performance data from the web server internal statistics and displays them in ASCII text.
To install perfdump, you need to make the following modifications in obj.conf in the netscape/server4/https-server_name/config directory:
You can request the perfdump statistics and inform the browser to automatically refresh the statistics every n seconds by using this URL, which sets the refresh to every 5 seconds:
ns-httpd pid: 133
|Using perfdump Statistics to Tune Your Server|
This section describes the information available through the perfdump utility and discusses how to tune some parameters to improve your server's performance. The default tuning parameters are appropriate for all sites except those with very high volume. The only parameter that large sites may regularly need to change is the RqThrottle parameter,
which is tunable from the Server Manager.
The perfdump utility monitors these statistics:
The listen socket is the listen queue size which is a socket-level parameter that specifies the number of incoming connections the system will accept for that socket. The default setting is 128 (for Unix/Linux) or 100 (for Windows NT) incoming connections. Make sure your system's listen-queue size is large enough to accommodate the size set in iPlanet Web Server. The listen queue size set from iPlanet Web Server changes the listen queue size requested by your system. If iPlanet Web Server requests a listen queue size larger than your system's maximum listen queue size, the size defaults to the system's maximum. Warning. Setting the listen queue too high can degrade server performance. It was designed to prevent the server from becoming overloaded with connections it cannot handle. If your server is overloaded and you increase the listen queue size, the server will only fall further behind. The first set of perfdump statistics is the listen socket (or listen queue) information. For each hardware virtual server you have enabled in your server, there is one ListenSocket structure. For most sites, only one is listed.
Set the listen queue using the Listen Queue field in the Server Manger, using the Performance Tuning page found in the Preferences tab, or by setting the ListenQ parameter in magnus.conf. If you are using virtual servers, there are two ways to create them: Using the virtual.conf file and using the obj.conf file. If you use the virtual.conf method, the 512 default maximum threads are available to all virtual servers on an as-needed basis. If you use the obj.conf method, the 512 threads are allocated equally to each of the defined virtual servers. For example, if you had two servers, each would have 256 threads available. This is less efficient. To maximize performance in this area, use the virtual.conf method. Address
This field contains the base address that this listen socket is listening to. For most sites that are not using hardware virtual servers, the URL is: http://INADDR_ANY:80" The constant value "INADDR_ANY" is known internally to the server that specifies that this listen socket is listening on all IP addresses for this machine. Tuning ActiveThreads
The total number of "threads" (HTTP sessions) that are in any state for this listen socket. This is equal to WaitingThreads + BusyThreads. This setting is not tunable. WaitingThreads
The number of "threads" (HTTP sessions) waiting for a new TCP connection for this listen socket. Tuning BusyThreads
The number of "threads" (HTTP sessions) actively processing requests which arrived on this listen socket. This setting is not tunable. Thread limits <min/max>
The minimum thread limit is a goal for how many threads the server attempts to keep in the WaitingThreads state. This number is just a goal. The number of actual threads in this state may go slightly above or below this value. The maximum threads represents a hard limit for the maximum number of active threads that can run simultaneously, which can become a bottleneck for performance. iPlanet Web Server has default limits of 48/512. For more information, see About RqThrottle (Maximum Simultaneous Connections). Tuning KeepAlive Information
This section provides statistics about the server's HTTP-level KeepAlive system.
The number of sessions currently waiting for a keepalive connection and the maximum number of sessions that the server allows to wait at one time. Tuning KeepAliveHits
The number of times a request was successfully received from a connection that had been kept alive. This setting is not tunable. KeepAliveFlushes
The number of times the server had to close a connection because the KeepAliveCount exceeded the KeepAliveMaxCount. This setting is not tunable. KeepAliveTimeout
Specifies the number of seconds the server will allow a client connection to remain open with no activity. A web client may keep a connection to the server open so that multiple requests to one server can be serviced by one network connection. Since a given server can handle a finite number of open connections (limited by active threads), a high number of open connections will prevent new clients from connecting. When SSL is enabled, KeepAliveTimeout defaults to 0, which effectively disables persistent connections. If you want to use persistent connections with SSL, set KeepAliveTimeout to a non-zero value. Tuning Cache Information
This information applies to the accelerator cache, not the file cache. For an explanation of the caches, see File and Accelerator Caches.
If the cache is disabled, the rest of this section is not displayed. Tuning Init fn=cache-init disable=true CacheEntries <CurrentCacheEntries / MaxCacheEntries>
The number of current cache entries and the maximum number of cache entries. A single cache entry represents a single URI. Tuning Init fn=cache-init MaxNumberOfCachedFiles=xxxxx CacheSize <CurrentCacheSize / MaxCacheSize>
The CacheSize has been deprecated for this release, since the files are cached in the file cache, not the accelerator cache. For more information, see File and Accelerator Caches. Hit Ratio <CacheHits / CacheLookups (Ratio)>
The hit ratio value tells you how efficient your site is. The hit ratio should be above 90%. If the number is 0, you need to optimize your site. See the troubleshooting section for more information on how to improve your site. If you are logging cookies and other special information, and you are seeing a very low hit rate (close to 0) refer to Chapter 8, "Understanding Log Files" for information on relaxed logging. Relaxed logging allows you to log special information and still use the accelorator cache. This setting is not tunable. pollInterval
Since pollInterval is deprecated for this release, this field displays MaxAge from nsfc.conf. If you have not tuned MaxAge, it defaults to 30 seconds. For tuning information on this setting, see MaxAge. DNS Cache Information
Server DNS cache disabled The DNS cache caches IP addresses and DNS names. enabled
If the cache is disabled, the rest of this section is not displayed. Tuning Init fn=dns-cache-init CacheEntries <CurrentCacheEntries / MaxCacheEntries>
The number of current cache entries and the maximum number of cache entries. A single cache entry represents a single IP address or DNS name lookup. Tuning Init fn=dns-cache-init cache-size=xxxxx HitRatio <CacheHits / CacheLookups (Ratio)>
The hit ratio is displays the number of cache hits and the number of cache lookups. A good hit ratio for the DNS cache is ~60-70%. This setting is not tunable. Native Thread Pools
Work queue length/Peak/Limit 0/0/0
The native thread pool (NativePool) is used internally by the server to execute NSAPI functions that require a native thread for execution. Since threads on Unix/Linux are always OS-scheduled (as opposed to user-scheduled) Unix/Linux users do not need to use the native thread pool. If you want to use a thread pool on Unix/Linux, you can set one up yourself. For more information, see Additional Thread Pools.iPlanet Web Server uses NSPR, which is an underlying portability layer that provides access to the host OS services. This layer provides abstractions for threads that are not always the same as those for the OS-provided threads. These non-native threads have lower scheduling overhead so their use improves performance. However, these threads are sensitive to blocking calls to the OS, such as I/O calls. To make it easier to write NSAPI extensions that can make use of blocking calls, the server keeps a pool of threads that safely support blocking calls (usually this means it is a native OS thread). During request processing, any NSAPI function that is not marked as being safe for execution on a non-native thread is scheduled for execution on one of the threads in the native thread pool. If you have written your own NSAPI plug-ins such as NameTrans, Service, or PathCheck functions, these execute by default on a thread from the native thread pool. If your plug-in makes use of the NSAPI functions for I/O exclusively or does not use the NSAPI I/O functions at all, then it can execute on a non-native thread. For this to happen, the function must be loaded with a "NativeThread=no" option indicating that it does not require a native thread. To do this, add the following to the "load-modules" Init line in the obj.conf file: Init funcs="pcheck_uri_clean_fixed_init" shlib="C:/Netscape/p186244/ P186244.dll" fn="load-modules" NativeThread="no" Windows NT uses can edit their native thread pool settings using the Server Manager. Additional Thread Pools
You can set up additional thread pools using the Server Manger's Preferences tab. Use thread pools to put a limit on the maximum number of requests answered by a service function at any moment. For example, these additional thread pools are a way to run thread-unsafe plugins. By defining a pool with a maximum number of threads set to 1, only one request is allowed into the specified service function. For more information on using the Server Manager to set up additional thread pools, see the online help. Idle/Peak/Limit
Idle indicates the number of threads that are currently idle. Peak indicates the peak number in the pool. Limit indicates the maximum number of native threads allowed in the thread pool, and is determined by the setting of NativePoolMaxThreads. For more information, see Native Thread Pool Size. Tuning Work queue length/Limit
These numbers refer to a queue of server requests that are waiting for the use of a native thread from the pool. The Work Queue Length is the current number of requests waiting for a native thread. Limit is the maximum number of requests that can be queued at one time to wait for a native thread., and is determined by the setting of the NativePoolQueueSize directive in magnus.conf. For more information, see Native Thread Pool Size. Tuning Peak work queue length
This is the highest number of requests that were ever queued up simultaneously for the use of a native thread since the server was started. This value can be viewed as the maximum concurrency for requests requiring a native thread. This setting is not tunable. Work queue rejections
This is the cumulative number of requests that have needed the use of a native thread, but that have been rejected due to the work queue being full. By default, these requests are rejected with a "503 - Service Unavailable" response. This setting is not tunable. PostThreadsEarly
This advanced tuning parameter changes the thread allocation algorithm by causing the server to check for threads available for accept before executing a request. The default is set to Off. Recommended only in those situations when the load on the server is primarily comprised of lengthy transactions such as LiveWire and the Netscape Application Server or custom applications that access databases and other complex back-end systems. Turning this on allows the server to grow its thread pool more rapidly. Tuning PostThreadsEarly 1 Native Thread Pool Size
In previous versions of the server, you controlled the native thread pool by setting system environment variables. In iPlanet Web Server, you can use the directives in magnus.conf to control the size of the native kernel thread pool. We recommend using the magnus.conf directives; however, if you have set the system environment variables previously, they override the magnus.conf directives. If you are using Windows NT, you can also change these settings using the Server Manager Native Thread Pool page. Use these directives to control the native thread pool.
NativePoolQueueSize. Determines the number of threads that can wait in the queue for the thread pool. If all threads in the pool are busy, then the next request-handling thread that needs to use a thread in the native pool must wait in the queue. If the queue is full, the next request-handling thread that tries to get in the queue is rejected, with the result that it returns a busy response to the client. It is then free to handle another incoming request instead of being tied up waiting in the queue.Thread Pool Environment Variables
NSCP_POOL_WORKQUEUEMAX. This value defaults to 0x7FFFFFFF (a very large number). Setting this below the RqThrottle value causes the server to execute a busy function instead of the intended NSAPI function whenever the number of requests waiting for service by pool threads exceeds this value. The default returns a "503 Service Unavailable" response and logs a message if LogVerbose is enabled. Setting this above RqThrottle causes the server to reject connections before a busy function can execute.This value represents the maximum number of concurrent requests for service which require a native thread. If your system is unable to fulfill requests due to load, letting more requests queue up increases the latency for requests and could result in all available request threads waiting for a native thread. In general, set this value to be high enough to avoid rejecting requests under "normal" conditions, which would be the anticipated maximum number of concurrent users who would execute requests requiring a native thread. The difference between this value and RqThrottle is the number of requests reserved for non-native thread requests (such as static HTML, gif, and jpeg files). Keeping a reserve (and rejecting requests) ensures that your server continues to fill requests for static files, which prevents it from becoming unresponsive during periods of very heavy dynamic content load. If your server consistently rejects connections, this value is set too low or your server hardware is overloaded.
NSCP_POOL_THREADMAX. This value represents the maximum number of threads in the pool. Set this value as low as possible to sustain the optimal volume of requests. A higher value allows more requests to execute concurrently, but has more overhead due to context switching, so "bigger is not always better." If you are not saturating your CPU but you are seeing requests queue up, then increase this number. Typically, you will not need to increase this number.Busy Functions
The default busy function returns a "503 Service Unavailable" response and logs a message if LogVerbose is enabled. You may wish to modify this behavior for your application. You can specify your own busy functions for any NSAPI function in the obj.conf file by including a service function in the configuration file in this format: For example, you could use this sample service function: This allows different responses if the server become too busy in the course of processing a request that includes a number of types (such as Service, AddLog, and PathCheck). Note that your busy function will apply to all functions that require a native thread to execute when the default thread type is non-native. To use your own busy function instead of the default busy function for the entire server, you can write an NSAPI init function that includes a func_insert call as shown below:
You can configure the server to use Domain Name System (DNS) lookups during normal operation. By default, DNS is not enabled; if you enable DNS, the server looks up the host name for a system's IP address. Although DNS lookups can be useful for server administrators when looking at logs, they can impact performance. When the server receives a request from a client, the client's IP address is included in the request. If DNS is enabled, the server must look up the hostname for the IP address for every client making a request. Enable Asynchronous DNS to avoid Multiple Thread Serialization
DNS causes multiple threads to be serialized when you use DNS services. If you do not want serialization, enable asynchronous DNS. You can enable it only if you have also enabled DNS. Enabling asynchronous DNS can improve your system's performance if you are using DNS. Note. If you turn off DNS lookups on your server, host name restrictions will not work, and hostnames will not appear in your log files. Instead, you'll see IP addresses. Caching DNS Entries
You can also specify whether to cache the DNS entries. If you enable the DNS cache, the server can store hostname information after receiving it. If the server needs information about the client in the future, the information is cached and available without further querying. You can specify the size of the DNS cache and an expiration time for DNS cache entries. The DNS cache can contain 32 to 32768 entries; the default value is 1024 entries. Values for the time it takes for a cache entry to expire can range from 1 second to 1 year (specified in seconds); the default value is 1200 seconds (20 minutes). Limit DNS Lookups to Asynchronous
It is recommended that you do not use DNS lookups in server processes because they are so resource intensive. If you must include DNS lookups, be sure to make them asynchronous. For more information on asynchronous DNS, see the Performance Tuning page in the online help. enabled
If asynchronous DNS is disabled, the rest of this section will not be displayed. Tuning NameLookups
The number of name lookups (DNS name to IP address) that have been done since the server was started. This setting is not tunable. AddrLookups
The number of address loops (IP address to DNS name) that have been done since the server was started. This setting is not tunable. LookupsInProgress
The current number of lookups in progress. This setting is not tunable.
Performance buckets allow you to define buckets, and link them to various server functions. Every time one of these functions is invoked, the server collects statistical data and adds it to the bucket. For example, send-cgi and NSServletService are functions used to serve the CGI and Java servlet requests respectively. You can either define two buckets to maintain separate counters for CGI and servlet requests, or create one bucket that counts requests for both types of dynamic content. The cost of collecting this information is little and impact on the server performance is negligible. This information can later be accessed using The perfdump Utility. The following information is stored in a bucket:
Specify all the configuration information for performance buckets in the obj.conf file. By default the feature is disabled. To enable performance measurement add the following line in obj.conf: The following examples show how to define new buckets. Init fn="define-perf-bucket" name="acl-bucket" description="ACL bucket"
Init fn="define-perf-bucket" name="file-bucket" description="Non-cached responses"
Init fn="define-perf-bucket" name="cgi-bucket" description="CGI Stats"
The prior example creates three buckets: acl-bucket, file-bucket, and cgi-bucket. To associate these buckets with functions, add bucket=bucket-name in front of the obj.conf function for which you wish to measure performance.
PathCheck fn="check-acl" acl="default" bucket="acl-
The server statistics in buckets can be accessed using The perfdump Utility. The performance buckets information is located in the last section of the report that perfdump returns. To enable reports on performance buckets, complete the following steps:
|File and Accelerator Caches|
In iPlanet Web Server there are two caches: a front-end accelerator cache that caches response headers and contains pointers to the static file cache, and a static file cache which holds static file information as well as content. The cache-init directive initializes the accelerator cache. The file cache is turned on by default. If you want to change the default cache setup, you need to create a file called nfsc.conf. For more information, see Configuring the File Cache.
The file cache is implemented using a new file cache module, NSFC, which caches static HTML, image and sound files. In previous versions of the server, the file cache was integrated with the accelerator cache for static pages. Therefore, an HTTP request was serviced by the accelerator, or passed to the NSAPI engine for full processing, and requests that could not be accelerated did not have the benefit of file caching. This prevented many sites with NSAPI plug-ins, customized logs, or used server-parsed HTML from taking advantage of the accelerator.
The NSFC module implements an independent file cache used in the NSAPI engine to cache static files that could not be accelerated. It is also used by the accelerator cache, replacing its previously integrated file cache. NSFC caches information that is used to speed up processing of server-parsed HTML.
Configuring the Accelerator Cache
The cache-init function controls the accelerator caching. To optimize server speed, you should have enough RAM for the server and cache because swapping can be slow. Do not allocate a cache that is greater in size than the amount of memory on the system.
Init fn="cache-init" MaxNumberOfCachedFiles=15000 MaxNumberOfOpenCachedFiles=15000 CacheHashSize=15101 Reaper=on ReaperInterval=3600 MaxFilesToReap=50
Using the Reaper Parameters
You configure the file cache in a text file nsfc.conf. You can also turn off caching for a specific directory by using the parameter nocache in the obj.conf file. Configuring nsfc.conf
By default, the file cache is turned on and uses the default values for all parameters described below. If you would like to change parameter values, you need to create a text file called nsfc.conf in the server_root/https-server-id/config directory. To change a parameter value for improved performance, type the parameter and its new value in the nsfc.conf file. CopyFiles
When CopyFiles is set to "true," the file is copied to a temporary file which the server displays when users access the file. Defaults to "false" on Unix/Linux and "true" on Windows NT. The temporary file is stored in the directory specified in TempDir.CopyFiles=true FileCacheEnable By default, this is set to true. FileCacheEnable=true HashInitSize HashInitSize=9131 HitOrder
If the MaxFiles limit has been reached when the server creates a new file cache entry, the server marks an existing entry for deletion. If HitOrder is set to "true" the file entry marked for deletion is the one that has received the fewest hits. If HitOrder is set to "false" the file entry marked for deletion is the one that has gone the longest without a hit.HitOrder=true MaxAge
The maximum age (in seconds) of a valid cache entry. This setting controls how long cached information will continue to be used once a file has been cached. An entry older than MaxAge is replaced by a new entry for the same file if the same file is referenced through the cache.Set MaxAge based on whether the content is updated (existing files are modified) on a regular schedule or not. For example, if content is updated four times a day at regular intervals, MaxAge could be set to 21600 seconds (6 hours). Otherwise, consider setting MaxAge to the longest time you are willing to serve the previous version of a content file, after the file has been modified. By default, this is set to 30. MaxAge=30 MaxFiles By default, this is set to 1024. MaxFiles=1024 MediumFileSizeLimit (Unix/Linux)
The size (in bytes) of the largest file that is not a "small" file that is considered to be "medium" size. The contents of medium files are cached by mapping the file into virtual memory (currently only on Unix/Linux platforms). The contents of "large" files (larger than "medium") are not cached, although information about large files is cached.By default, this is set to 525000 (525 KB). MediumFileSizeLimit=525000 MediumFileSpace By default, this is set to 10000000 (10MB). MediumFileSpace=10000000 SmallFileSizeLimit (Unix/Linux) The idea of distinguishing between small files and medium files is to avoid wasting part of many pages of virtual memory when there are lots of small files. So the SmallFileSizeLimit would typically be a slightly lower value than the VM page size. By default, this is set to 2048. SmallFileSizeLimit=2048 SmallFileSpace By default, this is set to 1MB for Unix/Linux, 0 for Windows NT. SmallFileSpace=1000000 TempDir If you assign a temporary directory, the server creates a structure within that directory for the temporary files. For example, on Windows NT if you set the temporary directory to C:/mytemp, the temporary files are created in the file C:/mytemp/c/server_doc_root. The c directory comes from the drive letter. TempDir=C:/temp TransmitFile
When TransmitFile is set to "true," open file descriptors are cached for files in the file cache, rather than the file contents, and PR_TransmitFile is used to send the file contents to a client. When set to "true," the distinction normally made by the file cache between small, medium, and large files no longer applies, since only the open file descriptor is being cached. By default, TransmitFile is "false" on Unix/Linux and "true" on Windows NT.This directive is intended to be used on Unix/Linux platforms that have native OS support for PR_TransmitFile, which currently includes HPUX and AIX. It is not recommended for other Unix/Linux platforms. TransmitFile=true Using the nocache Parameter
You can use the parameter nocache for the Service function send-file to specify that files in a certain directory not be cached. For example, if you have a set of files that changes too rapidly for caching to be useful, you can put them in a directory and instruct the server not to cache files in that directory. For example:
An object can be added to obj.conf to enable the NSFC file cache to be dynamically monitored and controlled while the server is running. Typically this would be done by first adding a NameTrans directive to the "default" object: Then add a new object definition: This enables the file cache control and monitoring function (nsfc-dump) to be accessed via the URI, "/nsfc." By changing the "from" parameter in the NameTrans directive, a different URI can be used. The following is an example of the information you receive when you access the URI:
|Unix/Linux Platform-Specific Issues|
The various Unix/Linux platforms all have limits on the number of files that can be open in a single process at one time. For busy sites, increase that number to 1024.
The following table shows the operating system tuning for HP-UX used when benchmarking for performance and scalability. These values are an example of how you might tune your system to achieve the desired result.
|Miscellaneous magnus.conf Directives|
You can use the following magnus.conf directives to configure your server to function more effectively:
Use this directive to set your Unix/Linux server in multi-process mode, which allows for higher scalability on multi-processor machines. If, for example, you are running on a four-processor CPU, setting MaxProcs to 4 improves performance: one process per processor.If you are running iPlanet Web Server in multi-process mode, you cannot run LiveWire, Web Publisher, and WAI. This directive results in one primordial process and four active processes: Note. This value is not tunable from the Server Manager. You must use magnus.conf. Accept Thread Information
MinAcceptThreadsPerSocket / MaxAcceptThreadsPerSocket
Use these directives to specify how many threads you want in accept mode on a listen socket at any time. It's a good practice to set this to equal the number of processes. You can set this to twice (2x) the number of processes, but setting it to a number that is too great (such as ten (10x) or fifty (50x)) allows too many threads to be created and slows the server down.Accept Timeout Information
Use this directive to specify the number of seconds the server waits between accepting a connection to a client and receiving information from it. The default setting is 30 seconds. Under most circumstances you should not have to change this setting. By setting it to less than the default 30 seconds, you can free up threads sooner. However, you may also disconnect users with slower connections.CGIStub Processes (Unix/Linux)
You can adjust the CGIStub parameters on Unix/Linux systems. In the iPlanet Web Server, the CGI engine creates CGIStub processes as needed to handle CGI processes. On systems that serve a large load and rely heavily on CGI-generated content, it is possible for the CGIStub processes spawned to consume all system resources. If this is happening on your server, the CGIStub processes can be tuned to restrict how many new CGIStub processes can be spawned, their timeout value, and the minimum number of CGIStub processes that will be running at any given moment. Note. If you have an init-cgi function in the obj.conf file and you are running in multi-process mode, you must add LateInit = yes to the init-cgi line. MinCGIStubs/MaxCGIStubs/CGIStubIdleTimeout MinCGIStubs controls the number of processes that are started by default. The first CGIStub process is not started until a CGI program has been accessed. The default value is 2. Note that if you have a init-cgi directive in the obj.conf file, the minimum number of CGIStub processes are spawned at startup. MaxCGIStubs controls the maximum number of CGIStub processes the server can spawn. This is the maximum concurrent CGIStub processes in execution, not the maximum number of pending requests. The default value shown should be adequate for most systems. Setting this too high may actually reduce throughput. The default value is 10. CGIStubIdleTimeout causes the server to kill any CGIStub processes that have been idle for the number of seconds set by this directive. Once the number of processes is at MinCGIStubs it does not kill any more processes. Buffer Size
You can specify the size of the send buffer (SndBufSize) and the receiving buffer (RcvBufSize) at the server's sockets. For more information regarding these buffers, see your Unix/Linux documentation.Strict HTTP Header Checking
The server provides strict HTTP header checking, rejecting connections that include inappropriately duplicated headers. If you want to supress this check, you can turn strict header checking off by setting the StrictHttpHeaders directive to off in magnus.conf:StrictHttpHeaders off About RqThrottle (Maximum Simultaneous Connections)
The RqThrottle parameter in the magnus.conf file specifies the maximum number of simultaneous transactions the web server can handle. The default value is 512. Changes to this value can be used to throttle the server, minimizing latencies for the transactions that are performed. The RqThrottle value acts across multiple virtual servers, but does not attempt to load-balance. To compute the number of simultaneous requests, the server counts the number of active requests, adding one to the number when a new request arrives, subtracting one when it finishes the request. When a new request arrives, the server checks to see if it is already processing the maximum number of requests. If it has reached the limit, it defers processing new requests until the number of active requests drops below the maximum amount. In theory, you could set the maximum simultaneous requests to 1 and still have a functional server. Setting this value to 1 would mean that the server could only handle one request at a time, but since HTTP requests for static files generally have a very short duration (response time can be as low as 5 milliseconds), processing one request at a time would still allow you to process up to 200 requests per second. However, in actuality, Internet clients frequently connect to the server and then do not complete their requests. In these cases, the server waits 30 seconds or more for the data before timing out. (You can define this timeout period in obj.conf. It has a default of 5 minutes.) Also, some sites do heavyweight transactions that take minutes to complete. Both of these factors add to the maximum simultaneous requests that are required. If your site is processing many requests that take many seconds, you may need to increase the number of maximum simultaneous requests. The defaults are 48/512. If your site is experiencing slowness and the ActiveThreads count remains close to the limit, consider increasing the maximum threads limit. To find out the active thread count, use The perfdump Utility. A suitable RqThrottle value ranges from 200-2000 depending on the load. If you want your server to use all the available resources on the system (that is, you don't run other server software on the same machine), then you can increase RqThrottle to a larger value than necessary without negative consequences. Note. If you are using older NSAPI plug-ins that are not reentrant, they will not work with the multithreading model described in this document. To continue using them, you should revise them so that they are reentrant. If this is not possible, you can configure your server to work with them by setting RqThrottle to 1 and then using a high value for MaxProcs, such as 48 or greater, but this will adversely impact your server's performance. Tuning If you edit the magnus.conf file, RqThrottleMinPerSocket is the minimum value and RqThrottle is the maximum value. The minimum limit is a goal for how many threads the server attempts to keep in the WaitingThreads state. This number is just a goal. The number of actual threads in this state may go slightly above or below this value. The default value is 48. The maximum threads represents a hard limit for the maximum number of active threads that can run simultaneously, which can become a bottleneck for performance. The default value is 512. If you use the Server Manager, follow these steps:
|Miscellaneous obj.conf Parameters|
You can use some obj.conf function parameters to improve your server's performance. In addition to the ones listed below, see Using the nocache Parameter for information on that parameter.
For more information on using obj.conf, see the NSAPI Programmer's Guide for iPlanet Web Server.
The parameter find-pathinfo-forward for the PathCheck function find-pathinfo and the NameTrans functions pfx2dir and assign-name can help you improve your performance. This parameter instructs the server to look for PATH_INFO forward in the path after ntrans-base instead of backward from the end of path in the server function find-pathinfo. Note. The server ignores the find-pathinfo-forward parameter if the ntrans- base parameter is not set in rq->vars when the server function find- pathinfo is called. By default, ntrans-base is set.
You can specify the parameter nostat in the NameTrans function assign-name to prevent the server from doing a stat on a specified URL whenever possible. Use the following syntax: For example:
|Tuning the ACL Cache|
Because of the default size of the cache (200 entries), the ACL cache can be a bottleneck or can simply not serve its purpose on a heavily trafficked site. On a heavily trafficked site well more than 200 users can hit ACL-protected resources in less time than the lifetime of the cache entries. When this situation occurs, the iPlanet Web Server has to query the LDAP server more often to validate users, which impacts performance.
This bottleneck can be avoided by increasing the size of the ACL cache with the ACLUserCacheSize directive in magnus.conf. Note that increasing the cache size will use more resources; the larger you make the cache the more RAM you'll need to hold it.
There can also be a potential (but much harder to hit) bottleneck with the number of groups stored in a cache entry (by default four). If a user belongs to five groups and hits five ACLs that check for these different groups within the ACL cache lifetime, an additional cache entry is created to hold the additional group entry. When there are two cache entries, the entry with the original group information is ignored.
While it would be extremely unusual to hit this possible performance problem, the number of groups cached in a single ACL cache entry can be tuned with the ACLGroupCacheSize directive.
Using magnus.conf Directives
In order to adjust the cache values you will need to manually add these directives to your magnus.conf file. ACLCacheLifetime
Set this directive to a number that determines the number of seconds before the cache entries expire. Each time an entry in the cache is referenced, its age is calculated and checked against ACLCacheLifetime. The entry is not used if its age is greater than or equal to the ACLCacheLifetime. The default value is 120 seconds. If this value is set to 0, the cache is turned off. If you use a large number for this value, you may need to restart the iPlanet Web Server when you make changes to the LDAP entries. For example, if this value is set to 120 seconds, the iPlanet Web Server might be out of sync with the LDAP server for as long as two minutes. If your LDAP is not likely to change often, use a large number. ACLUserCacheSize
Set this directive to a number that determines the size of the User Cache (default is 200). ACLGroupCacheSize
Set this directive to a number that determines how many group IDs can be cached for a single UID/cache entry (default is 4). Verifying Settings Using LogVerbose
If you set LogVerbose to on, you can verify that the ACL cache settings are being used. When LogVerbose is running you should expect to see these messages in your errors log when the server starts:
|Common Performance Problems|
This section discusses a few common performance problems to check for on your web site:
If you need iPlanet Web Server to run in low-memory situations, try reducing the thread limit to a bare minimum by lowering the value of RqThrottle in your magnus.conf file. Also you may want to reduce the maximum number of processes that the iPlanet Web Server will spawn by lowering the value of the MaxProcs value in the magnus.conf file. Under-Throttled Server
The server does not allow the number of active threads to exceed the Thread Limit value. If the number of simultaneous requests reaches that limit, the server stops servicing new connections until the old connections are freed up. This can lead to increased response time. In iPlanet Web Server, the server's default RqThrottle value is 512. If you want your server to accept more connections, you need to increase the RqThrottle value. Checking
The symptom of an under-throttled server is a server with a long response time. Making a request from a browser establishes a connection fairly quickly to the server, but on under-throttled servers it may take a long time before the response comes back to the client. The best way to tell if your server is being throttled is to look at the WaitingThreads count. If this number is getting close to 0 or is 0, then the server is not accepting new connections right now. Also check to see if the number of ActiveThreads and BusyThreads are close to their limits. If so, the server is probably limiting itself. Tuning
See About RqThrottle (Maximum Simultaneous Connections). Cache Not Utilized
If the cache is not utilized, your server is not performing optimally. Since most sites have lots of GIF or JPEG files (which should always be cacheable), you need to use your cache effectively. Some sites, however, do almost everything through CGIs, SHTML, or other dynamic sources. Dynamic content is generally not cacheable and inherently yields a low cache hit rate. Don't be too alarmed if your site has a low cache hit rate. The most important thing is that your response time is low. You can have a very low cache hit rate and still have very good response time. As long as your response time is good, you may not care that the cache hit rate is low. Checking
Begin by checking your Hit Ratio. This is the percentage of times the cache was used with all hits to your server. A good cache hit rate is anything above 50%. Some sites may even achieve 98% or higher. In addition, if you are doing a lot of CGI or NSAPI calls, you may have a low cache hit rate. Tuning
If you have custom NSAPI functions (nametrans, pathcheck, etc), you may have a low cache hit rate. If you are writing your own NSAPI functions, be sure to see the programmer's guide for information on making your NSAPI code cacheable as well. KeepAlive Connections Flushed
A web site that might be able to service 75 requests per second without KeepAlives may be able be able to do 200-300 requests per second when keepalives are enabled. Therefore, as a client requests various items from a single page, it is important that keepalives are being used effectively. If the KeepAliveCount exceeds the KeepAliveMaxCount, subsequent KeepAlive connections will be closed (or "flushed") instead of being honored and kept alive. Checking
Check the KeepAliveFlushes and KeepAliveHits values. On a site where KeepAlives are running well, the ratio of KeepAliveFlushes to KeepAliveHits is very low. If the ratio is high (greater than 1:1), your site is probably not utilizing the HTTP KeepAlives as well as it could. Tuning
To reduce KeepAlive flushes, increase the MaxKeepAliveConnections value in the magnus.conf file. The default value is 200. By raising the value, you keep more waiting keepalive connections open. Warning. On Unix/Linux systems, if you increase the MaxKeepAliveConnections value too high, the server can run out of open file descriptors. Typically 1024 is the limit for open files on Unix/Linux, so increasing this value above 500 is not recommended. Log File Modes
Keeping the log files on verbose mode can have a significant affect of performance. Client-Host, Full-Request, Method, Protocol, Query-String, URI, Referer, User-Agent, Authorization and Auth-User: Because the "obscure" variable cannot be provided by the internal "accelerated" path, the accelerated path will not be used at all. Therefore performance numbers will decrease significantly for requests that would typically benefit from the accelerator, for example static files and images. iPlanet Web Server has a relaxed logging mode that eases the requirements of the log subsystem. Adding "relaxed.logname=anything" to the "flex-init" line in obj.conf changes the behavior of the server in the following way: Logging variables other than the "blessed few" does not prevent the accelerated path from being used. If the accelerator is used, the "non-blessed" variable (which is then not available internally) will be logged as "-". The server does not use the accelerator for dynamic content like CGIs or SHTML, so all the variables would be logged correctly for these requests. Using Local Variables
For information on improving servlet performance, see the Programmer's Guide to Servlets in iPlanet Web Server.
This section examines subsystems of your server and makes some recommendations for optimal performance:
On Solaris and Windows NT, iPlanet Web Server transparently takes advantage of multiple CPUs. In general, the effectiveness of multiple CPUs varies with the operating system and the workload. Dynamic content performance improves the most as more processors are added to the system. Because static content involves mostly IO and more primary memory means more caching of the content (assuming the server is tuned to take advantage of the memory) more time is spent in IO rather than any busy CPU activity. Our study of dynamic content performance on a four-CPU machine indicate a 40-60% increase for NSAPI and about 50-80% increase for servlets. Memory
As a baseline, iPlanet Web Server requires 64MB RAM. If you have multiple CPUs, get at least 64MB per CPU. For example, if you have four CPUs, you should install at least 256MB RAM for optimal performance. At high numbers of peak concurrent users, also allow extra RAM for the additional threads. After the first 50 concurrent users, add an extra 512KB per peak concurrent user. Drive Space
You need to have enough drive space for your OS, document tree, and log files. In most cases 2GB total is sufficient. Put the OS, swap/paging file, iPlanet Web Server logs, and document tree each on separate hard drives. Thus, if your log files fill up the log drive, your OS will not suffer. Also, you'll be able to tell whether, for example, the OS paging file is causing drive activity. Your OS vendor may have specific recommendations for how much swap or paging space you should allocate. Based on our testing, iPlanet Web Server performs best with swap space equal to RAM, plus enough to map the document tree. Networking
For an Internet site, decide how many peak concurrent users you need the server to handle, and multiply that number of users by the average request size on your site. Your average request may include multiple documents. If you're not sure, try using your home page and all its associated subframes and graphics. Next decide how long the average user will be willing to wait for a document, at peak utilization. Divide by that number of seconds. That's the WAN bandwidth your server needs. For example, to support a peak of 50 users with an average document size of 24kB, and transferring each document in an average of 5 seconds, we need 240 KBytes/s - or 1920 kbit/s. So our site needs two T1 lines (each 1544 kbit/s). This allows some overhead for growth, too. Your server's network interface card should support more than the WAN it's connected to. For example, if you have up to 3 T1 lines, you can get by with a 10BaseT interface. Up to a T3 line (45 Mbit/s) you can use 100BaseT. But if you have more than 50 Mbit/s of WAN bandwidth, consider configuring multiple 100BaseT interfaces, or look at Gigabit Ethernet technology. For an intranet site, your network is unlikely to be a bottleneck. However, you can use the same calculations as above to decide.