iPlanet Web Server 6.0 Performance Tuning, Sizing, and Scaling Guide
This guide is intended for advanced administrators only. Be cautious when you tune your server. Do not change any values except in exceptional circumstances. Read this guide and other relevant server doc-umentation before making any changes. Always backup your configuration files first.
The following topics are covered in this guide:
- About Server Performance
- Monitoring Current Activity Using the Server Manager
- Monitoring Current Activity Using the perfdump Utility
- Using Statistics to Tune Your Server
- Using Performance Buckets
- Configuring the File Cache
- Tuning the ACL User Cache
- Using Quality of Service
- Using Load Balancing
- Threads, Processes, and Connections
- Unix/Linux Platform-Specific Issues
- Improving Java Performance
- Miscellaneous magnus.conf Directives
- Miscellaneous obj.conf Parameters
- Common Performance Problems
- Tuning Solaris for Performance Benchmarking
- Sizing and Scaling Your Server
- Scalability Studies
About Server Performance
iPlanet Web Server was designed to meet the needs of the most demanding, high traffic sites in the world. It runs flexibly 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.
Your customers' needs may vary significantly. This guide helps you define your server workload and size a system to meet your performance needs. This guide addresses miscellaneous configuration and Unix/Linux platform-specific issues. It also describes theperfdumpperformance utility and tuning parameters that are built into the server.
Virtual Servers
Virtual servers add another layer to the performance improvement process. Certain settings are tunable for the entire server, while others are based on an individual virtual server. You can also use the quality of service (QOS) features to set resource utilization constraints for an individual virtual server or class of virtual servers. For example, you can use the quality of service features to limit the number of connections allowed for a virtual server or class of virtual servers.
Performance Issues
The first step toward sizing your server is to determine your requirements. Performance means different things to users than 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%. In addition, for virtual servers the goal might be to provide a targeted level of performance at different price points. You need to define what performance means for your particular situation.
Here are some areas to consider:
- Number of peak concurrent users
- Security requirements
- 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 load. SSL always has a significant impact on throughput, so for best performance minimize your use of SSL, or consider using a multi-CPU server to handle it.
- Size of doc-ument tree
- Dynamic vs. static content
- The content you serve affects your server's performance. An iPlanet Web Server delivering mostly static HTML can run much faster than a server that has to execute CGIs for every query.
- When running an SSL server on Solaris without the use of Java, performance gains can be achieved by enablingSmartHeap.SmartHeapcan be enabled by uncommenting a few lines in the server's start script.
- SmartHeapis not currently compatible with Java on iPlanet Web Server 6.0.
Monitoring Performance
You can monitor the performance of your server by:
- Monitoring Current Activity Using the Server Manager
- Monitoring Current Activity Using the perfdump Utility
- Using Performance Buckets
- Using Quality of Service
- Using Load Balancing
Monitoring Current Activity Using the Server Manager
iPlanet Web Server lets you monitor many performance statistics through the Server Manager user interface and throughstats-xml. Once statistics are enabled, you can monitor them in the following areas:
Enabling Statistics
You must enable statistics on you iPlanet Web Server before you will be able to monitor performance. This can be done through the Server Manager or editing theobj.confandmagnus.conffiles.
Enabling Statistics from the Server Manager
To enable statistics from the user interface, follow these steps:
- From the Server Manager, select the Monitor tab.
- Select Monitor Current Activity.
- Select Yes to enable.
- Click OK.
- Click Apply.
- Select Apply Changes to restart the server for your changes to take effect.
Enabling Statistics with stats-xml
You can also enable statistics directly by editingobj.confandmagnus.conf. Users who create automated tools or write customized programs for monitoring and tuning may prefer to work directly withstats-xml.
To enable the statistics usingstats-xml, follow these steps:
- Under the default object inobj.conf, add the following line:
- Add the following Service function toobj.conf:
- Add thestats-initSAF tomagnus.conf.
- update-interval.The period in seconds between statistics updates. A higher setting (less frequent) will be better for performance. The minimum value is 1; the default value is 5.
- virtual-servers.The maximum number of virtual servers for which you track statistics. This number should be set equal to or higher than the number of virtual servers configured. Smaller numbers result in lower memory usage. The minimum value is 1; the default is 1000.
- profiling.Enable NSAPI performance profiling. The default is "no" which results in slightly better server performance. However, if you enable statistics through the user interface, profiling is turned on by default.
Monitoring Statistics
Once you've enabled statistics, you can get a variety of information on how your server instance and your virtual servers are running. The statistics are broken up into functional areas.
To monitor statistics from the Server Manager, follow these steps:
- From the Server Manager, select the Monitor tab.
- Select Monitor Current Activity.
- Make sure that Statistics /Profiling is enabled.
- Select the refresh interval from the drop-down list under Monitor Web Server Statistics:
- The refresh interval is the number of seconds between updates of the statistics information displayed.
- Select the type of web server statistics to display from the drop-down list:
- Click Submit.
- A page appears displaying the type of statistics you selected. The page is updated every 5-15 seconds, depending upon what you chose for the refresh interval. All pages will display a bar graph of activity, except for Connections.
- Select the process ID from the drop-down list.
Virtual Server Statistics
Virtual Server statistics can be viewed from the Server Manager. Here you can choose to display statistics for the server instance, an individual virtual server, or all. This information is not provided throughperfdump.
Monitoring Current Activity Using the perfdump Utility
Theperfdumputility is an SAF built into iPlanet Web Server that collects various pieces of performance data from the web server internal statistics and displays them in ASCII text. Theperfdumputility allows you to monitor a greater variety of statistics than available through the Server Manager.
Changes to perfdump in this Release
The biggest change inperfdumpfor the 6.0 release is that the statistics are now unified. Previouslyperfdumponly monitored a single process. Now the statistics, for example file cache size and number of threads, are multiplied by the number of processes to give you a more accurate view of the server as a whole. The categories in the.perfoutput have changed as well.
Installing the perfdump Utility
To installperfdump, you need to make the following modifications inobj.conf:
- Add the following object to yourobj.conffile after the default object:
- Add the following to the default object:
- If not already enabled, enablestats-xml.
- If you need to enablestats-xml, seeEnabling Statistics.
- Restart your server software.
- Accessperfdumpby entering this URL:
- http://yourhost/.perf?refresh=5
- For more information on editing the configuration files, see theNSAPI Programmer's Guide.
Using Statistics to Tune Your Server
This section describes the information available through theperfdumputility 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 parameters that large sites may regularly need to change areRqThrottle,MaxKeepAliveConnections, andKeepAliveTimeout, which are tunable frommagnus.confand the Server Manager.
Theperfdumputility monitors statistics in these categories:
- Connection Queue Information
- Listen Socket Information
- Keep-Alive/Persistent Connection Information
- Session Creation Information
- Cache Information
- Thread Pools
- DNS Cache Information
- Asynchronous DNS Lookup (Unix/Linux Only)
- The Performance Tuning page
- The File Cache Configuration page
- The Treads page (Unix)
- The Native Threads page (NT)
- The Generic Threads page (NT)
- The Magnus Editor
Connection Queue Information
Connection queue information shows the number of sessions in the queue, and the average delay before the connection is accepted.
Following is an example of how these statistics are displayed inperfdump:
ConnectionQueue:
---------------------------------
Current/peak/limit queue length 0/48/5000
Total connections queued 3753
Average queueing delay 0.0013 seconds
Current /peak /limit
Current/peak/limit queue length shows, in order:
- The number of connections currently in the queue
- The largest number of connections that have been in the queue simultaneously;
- The maximum size of the connection queue.
Tuning
If the peak queue length is close to the limit, you may wish to increase the maximum connection queue size to avoid dropping connections under heavy load.
You can increase the connection queue size by:
- Setting or changing the value ofConnQueueSizein the Magnus Editor of the Server Manager
- Editing theConnQueueSizedirective inmagnus.conf
Total Connections Queued
Total connections queued is the total number of times a connection has been queued. This includes newly accepted connections and connections from the keep-alive system.
Average Queuing Delay
Average queueing delay is the average amount of time a connection spends in the connection queue. This represents the delay between when a request connection is accepted by the server, and a request processing thread (also known as a session) begins servicing the request.
Listen Socket Information
This listen socket information includes the IP address, port number, number of acceptor threads, and the default virtual server for the listen socket. For tuning purposes, the most important field in the listen socket information is the number of acceptor threads.
You can have many listen sockets enabled for virtual servers, but you will at least have one (usually http://0.0.0.0:80) enabled for your default server instance.
ListenSocket ls1:
------------------------
Address http://0.0.0.0:1890
Acceptor threads 1
Default virtual server test
Tuning
You can create listen sockets through the Server Manager, and edit much of a listen socket's information. For more information, see "Adding and Editing Listen Sockets," on page 150 of theAdministrator's Guide.
If you have created multiple listen sockets,perfdumpdisplays them all.
Set the TCP/IP listen queue size for all listen sockets by:
- Editing theListenQparameter inmagnus.conf
- Setting or changing theListenQvalue in the Magnus Editor of the Server Manager
- Entering the value in the Listen Queue Size field of the Performance Tuning page of the Server Manager
Address
This field contains the base address that this listen socket is listening on. It contains the IP address and the port number.
If your listen socket listens on all IP addresses for the machine, the IP part of the address is 0.0.0.0.
Tuning
This setting is tunable when you edit a listen socket. If you specify an IP address other than 0.0.0.0, the server will make one less system call per connection. Specify an IP address other than 0.0.0.0 for best possible performance.
For more information, see "Adding and Editing Listen Sockets," on page 150 of theAdministrator's Guide.
Acceptor Threads
Acceptor threads are threads that wait for connections. The threads accept connections and put them in a queue where they are then picked up by worker threads. Ideally, you want to have enough acceptor threads so that there is always one available when a user needs one, but few enough so that they do not provide too much of a burden on the system. A good rule is to have one acceptor thread per CPU on your system. You can increase this value to about double the number of CPUs if you find indications of TCP/IP listen queue overruns.
Tuning
You can tune this number through the user interface when you edit a listen socket. For more information, see "Adding and Editing Listen Sockets," on page 150 of theAdministrator's Guide.
Default Virtual Server
Software virtual servers work using the HTTP 1.1 Host header. If the end user's browser does not send the host header, or if the server cannot find the virtual server specified by the Host header, iPlanet Web Server handles the request using a default virtual server. Also, for hardware virtual servers, if iPlanet Web Server cannot find the virtual server corresponding to the IP address, it displays the default virtual server. You can configure the default virtual server to send an error message or serve pages from a special doc-ument root.
Tuning
You can specify a default virtual server for an individual listen socket and for the server instance. If a given listen socket does not have a default virtual server, the server instance's default virtual server is used.
You can specify a default virtual server for a listen socket by:
- Setting or changing the default virtual server information using the Edit Listen Sockets page on the Preferences Tab of the Server Manger. The settings for the default virtual server are on the Connection Group Settings page that appears when you click Groups.
- Editing thedefaultvsattribute of theCONNECTIONGROUPelement in theserver.xmlfile. For more information, see the chapter onserver.xmlin theNSAPI Programmer's Guide.
Keep-Alive/Persistent Connection Information
This section provides statistics about the server's HTTP-level keep-alive system.
The following example shows the keep-alive statistics displayed byperfdump:
KeepAliveInfo:
--------------------
KeepAliveCount 1/256
KeepAliveHits 4
KeepAliveFlushes 1
KeepAliveTimeout 30 seconds
Both HTTP 1.0 and HTTP 1.1 support the ability to send multiple requests across a single HTTP session. A web server can receive hundreds of new HTTP requests per second. If every request was allowed to keep the connection open indefinitely, the server could become overloaded with connections. On Unix/Linux systems this could lead to a file table overflow very easily.
To deal with this problem, the server maintains a "Maximum number of `waiting' keep-alive connections" counter. A `waiting' keep-alive connection has fully completed processing the previous request, and is now waiting for a new request to arrive on the same connection. If the server has more than the maximum waiting connections open when a new connection waits for a keep-alive request, the server closes the oldest connection. This algorithm keeps an upper bound on the number of open waiting keep-alive connections that the server can maintain.
iPlanet Web Server does not always honor a keep-alive request from a client. The following conditions cause the server to close a connection even if the client has requested a keep-alive connection:
- KeepAliveTimeoutis set to 0.
- MaxKeepAliveConnectionscount is exceeded.
- Dynamic content, such as a CGI, does not have an HTTPcontent-lengthheader set. This applies only to HTTP 1.0 requests. If the request is HTTP 1.1, the server honors keep-alive requests even if thecontent-lengthis not set. The server now can use chunked encoding for these requests if the client can handle them (indicated by the request headertransfer-encoding:chunked). For more information regarding chunked encoding, see theNSAPI Programmer's Guide.
- Request is notHTTP GETorHEAD.
- The request was determined to be bad. For example if the client sends only headers with no content.
KeepAliveThreads
You can configure the number of threads used in the keep-alive system by:
- Editing theKeepAliveThreadsparameter inmagnus.conf
- Setting or changing theKeepAliveThreadsvalue in the Magnus Editor of the Server Manager
KeepAliveCount
This setting has two numbers:
- Number of connections in keep-alive mode
- Maximum number of connections allowed in keep-alive mode simultaneously
Tuning
You can tune the maximum number of sessions that the server allows to wait at one time before closing the oldest connection by:
- Editing theMaxKeepAliveConnectionsparameter in themagnus.conffile
- Setting or changing theMaxKeepAliveConnectionsvalue in the Magnus Editor of the Server Manager
KeepAliveHits
The number of times a request was successfully received from a connection that had been kept alive.
KeepAliveFlushes
The number of times the server had to close a connection because theKeepAliveCountexceeded theMaxKeepAliveConnections.
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 a single network connection. Since a given server can handle a finite number of open connections, a high number of open connections will prevent new clients from connecting.
Tuning
You can changeKeepAliveTimeoutby:
- Editing theKeepAliveTimeoutparameter inmagnus.conf
- Setting or changing theKeepAliveTimeoutvalue in the Magnus Editor of the Server Manager
- Entering the value in the HTTP Persistent Connection Timeout field of the Performance Tuning page in the Server Manager
UseNativePoll
This option is not displayed inperfdumpor Server Manager statistics. However, for Unix /Linux users, it should be enabled for maximum performance.
To enable native poll for your keep-alive system from the Server Manager, follow these steps:
- Go to the Server Manager Preferences tab and select the Magus Editor.
- From the drop-down list choose, Keep-Alive Settings and click Manage.
- Use the drop-down list to setUseNativePollto on.
- Click OK.
- Click Apply.
- Select Apply Changes to restart the server for your changes to take effect.
Session Creation Information
Session creation statistics are only displayed inperfdump. Following is an example ofSessionCreationInfodisplayed inperfdump:
SessionCreationInfo:
------------------------
Active Sessions 1
Total Sessions Created 48/512
Active Sessions shows the number of sessions (request processing threads) currently servicing requests.
Total Sessions Created shows both the number of sessions that have been created and the maximum number of sessions allowed.
Reaching the maximum number of configured threads is not necessarily undesirable, and you need not automatically increase the number of threads in the server. Reaching this limit means that the server needed this many threads at peak load, but as long as it was able to serve requests in a timely manner, the server is adequately tuned. However, at this point connections will queue up in the connection queue, potentially overflowing it. If you check yourperfdumpoutput on a regular basis and notice that total sessions created is often near theRqThrottlemaximum, you should consider increasing your thread limits.
Tuning
You can increase your thread limits by:
- Editing theRqThrottleparameter inmagnus.conf
- Setting or changing theRqThrottlevalue in the Magnus Editor of the Server Manager
- Entering the value in the Maximum Simultaneous Requests field of the Performance Tuning page in the Server Manager
Cache Information
The Cache information section provides statistics on how your file cache is being used. The file cache caches static content so that the server handles requests for static content quickly. Following is an example of how the cache statistics are displayed inperfdump:
CacheInfo:
------------------
enabled yes
CacheEntries 5/1024
Hit Ratio 93/190 ( 48.95%)
Maximum age 30
enabled
If the cache is disabled, the rest of this section is not displayed.
Tuning
The cache is enabled by default. You can disable it by:
- Unselecting it from the File Cache Configuration page under Preferences in the Server Manger
- Editing theFileCacheEnableparameter in thensfc.conffile. For more information, see theNSAPI Programmer's Guide.
CacheEntries
The number of current cache entries and the maximum number of cache entries are both displayed. A single cache entry represents a single URI.
Tuning
You can set the maximum number of cached entries by:
- Entering a value in the Maximum Number of Files field on the File Cache Configuration page under Preferences in the Server Manger
- Creating or editing theMaxFilesparameter in thensfc.conffile. For more information, see theNSAPI Programmer's Guide.
Hit Ratio (CacheHits / CacheLookups)
The hit ratio gives you the number of file cache hits versus cache lookups. Numbers approaching 100% indicate the file cache is operating effectively, while numbers approaching 0% could indicate that the file cache is not serving many requests.
Maximum age
The maximum age displays the maximum age of a valid cache entry. This parameter controls how long cached information is used after a file has been cached. An entry older than the maximum age is replaced by a new entry for the same file.
Tuning
If your web site's content changes infrequently, you may want to increase this value for improved performance. You can set the maximum age by:
- Entering or changing the value in the Maximum Age field of the File Cache Configuration page in the Server Manager
- Editing theMaxAgeparameter in thensfc.conffile. For more information, see theNSAPI Programmer's Guide.
Thread Pools
Three types of thread pools can be configured through the Server Manager:
Thread Pools (Unix /Linux only)
Since threads on Unix/Linux are always operating system (OS)-scheduled, as opposed to user-scheduled, Unix/Linux users do not need to use native thread pools, and this option is not offered in their user interface. However, you can edit the OS-scheduled thread pools and add new thread pools if needed, using the Server Manager.
Native Thread Pools (NT only)
On NT, the native thread pool (NativePool) is used internally by the server to execute NSAPI functions that require a native thread for execution.
Native pools:
----------------------------
NativePool:
Idle/Peak/Limit 1/1/128
Work queue length/Peak/Limit 0/0/0
Windows NT uses can edit their native thread pool settings using the Server Manager.
iPlanet Web Server uses NSPR, which is an underlying portability layer providing 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. This usually 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 asNameTrans,Service, orPathCheckfunctions, 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 aNativeThread="no"option, indicating that it does not require a native thread.
To do this, add the following to the "load-modules"Initline in themagnus.conffile:
Init funcs="pcheck_uri_clean_fixed_init" shlib="C:/Netscape/p186244/P186244.dll" fn="load-modules" NativeThread="no"
TheNativeThreadflag affects all functions in thefuncslist, so if you have more than one function in a library, but only some of them use native threads, use separateInitlines.
Generic Thread Pools (NT only)
On NT, you can set up additional thread pools using the Server Manger. Use thread pools to put a limit on the maximum number of requests answered by a service function at any moment. Additional thread pools are a way to run thread-unsafe plug-ins. By defining a pool with a maximum number of threads set to 1, only one request is allowed into the specified service function.
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 ofNativePoolMaxThreads.
Tuning
You can modify theNativePoolMaxThreadsby:
- Editing theNativePoolMaxThreadsparameter inmagnus.conf
- Entering or changing the value in the Maximum Threads field of the Native Thread Pool page in the Server Manager
Work Queue Length /Peak /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.
Peak 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.
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 ofNativePoolQueueSize.
Tuning
You can modify theNativePoolQueueSizeby:
- Editing theNativePoolQueueSizeparameter inmagnus.conf
- Entering or changing the value in the Queue Size field of the Native Thread Pool page in the Server Manager
NativePoolStackSize
TheNativePoolStackSizedetermines the stack size in bytes of each thread in the native (kernel) thread pool.
Tuning
You can modify theNativePoolStackSizeby:
- Editing theNativePoolStackSizeparameter inmagnus.conf
- Setting or changing theNativePoolStackSizevalue in the Magnus Editor of the Server Manager
- Entering or changing the value in the Stack Size field of the Native Thread Pool page in the Server Manager
NativePoolQueueSize
TheNativePoolQueueSizedetermines 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.
Setting TheNativePoolQueueSizelower than theRqThrottlevalue 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 ifLogVerboseis enabled. Setting TheNativePoolQueueSizehigher thanRqThrottlecauses 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 by anticipating the maximum number of concurrent users who would execute requests requiring a native thread.
The difference between this value andRqThrottleis the number of requests reserved for non-native thread requests, such as static HTML and image 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 either set too low, or your server hardware is overloaded.
Tuning
You can modify theNativePoolQueueSizeby:
- Editing theNativePoolQueueSizeparameter inmagnus.conf
- Entering or changing the value in the Queue Size field of the Native Thread Pool page in the Server Manager
NativePoolMaxThreads
NativePoolMaxThreadsdetermine the maximum number of threads in the native (kernel) thread pool.
A higher value allows more requests to execute concurrently, but has more overhead due to context switching, so "bigger is not always better." Typically, you will not need to increase this number, but if you are not saturating your CPU and you are seeing requests queue up, then you should increase this number.
Tuning
You can modify theNativePoolMaxThreadsby:
- Editing theNativePoolMaxThreadsparameter inmagnus.conf
- Entering or changing the value in the Maximum Threads field of the Native Thread Pool page in the Server Manager
NativePoolMinThreads
Determines the minimum number of threads in the native (kernel) thread pool.
Tuning
You can modify theNativePoolMinThreadsby:
- Editing theNativePoolMinThreadsparameter inmagnus.conf
- Setting or changing theNativePoolMinThreadsvalue in the Magnus Editor of the Server Manager
- Entering or changing the value in the Minimum Threads field of the Native Thread Pool page in the Server Manager
DNS Cache Information
The DNS cache caches IP addresses and DNS names. Your server's DNS cache is disabled by default. In the DNS Statistics for Process ID All page under Monitor in the Server Manager the following statistics are displayed:
enabled
If the DNS cache is disabled, the rest of this section is not displayed.
Tuning
By default, the DNS cache is off. You can enable DNS caching by:
- Adding the following line tomagnus.conf:
- Setting the DNS value to on in the Magnus Editor of the Server Manager
- Selecting DNS Enabled from the Performance Tuning page under Preferences in the Server Manger
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. The cache should be as large as the maximum number of clients that will access your web site concurrently. Note that setting the cache size too high will waste memory and degrade performance.
Tuning
You can set the maximum size of the DNS cache by:
- Adding the following line to themagnus.conffile:
- Entering or changing the value in the Size of DNS Cache field of the Performance Tuning page in the Server Manager
HitRatio (CacheHits / CacheLookups)
The hit ratio displays the number of cache hits versus the number of cache lookups.
Asynchronous DNS Lookup (Unix/Linux Only)
You can configure the server to use Domain Name System (DNS) lookups during normal operation. By default, DNS is not enable. 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 seriously 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. Do not enable DNS lookup for high-volume servers.
In order for asynchronous DNS lookups to work correctly, the DNS resolver must be properly configured. See your operating system doc-umentation for details.
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. 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.
enabled
If asynchronous DNS is disabled, the rest of this section will not be displayed.
Tuning
You can enable asynchronous DNS by:
- AddingAsyncDNS onin themagnus.conffile
- Setting theAsyncDNSvalue to on in the Magnus Editor of the Server Manager
- Selecting Async DNS Enabled from the Performance Tuning page under Preferences in the Server Manger
NameLookups
The number of name lookups (DNS name to IP address) that have been done since the server was started.
AddrLookups
The number of address loops (IP address to DNS name) that have been done since the server was started.
LookupsInProgress
The current number of lookups in progress.
Busy Functions
The default busy function returns a "503 Service Unavailable" response and logs a message ifLogVerboseis enabled. You may wish to modify this behavior for your application. You can specify your own busy functions for any NSAPI function in theobj.conffile by including a service function in the configuration file in this format:
To use your own busy function instead of the default busy function for the entire server, you can write an NSAPIinitfunction that includes afunc_insertcall as shown below:
Using Performance Buckets
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-cgiandNSServletServiceare 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 usually negligible. This information can later be accessed using . The following information is stored in a bucket:
- Name of the bucket.This name is used for associating the bucket with a function.
- Description.A description of the functions that the bucket is associated with.
- Number of requests for this function.The total number of requests that caused this function to be called.
- Number of times the function was invoked.This number may not coincide with the number of requests for the function because some functions may be executed more than once for a single request.
- Function latency or the dispatch time.The time taken by the server to invoke the function.
- Function time.The time spent in the function itself.
Configuration
You must specify all the configuration information for performance buckets in themagnus.confandobj.conffiles. Only the default bucket is automatically enabled.
The following examples show how to define new buckets inmagnus.conf:
The prior example creates three buckets:acl-bucket,file-bucket, andcgi-bucket. To associate these buckets with functions, addbucket=bucket-nameto theobj.conffunction for which you wish to measure performance. For example:
PathCheck fn="check-acl" acl="default" bucket="acl-bucket"
...
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file" bucket="file-bucket"
...
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi" bucket="cgi-bucket"
</Object>
Performance Report
The server statistics in buckets can be accessed using . The performance buckets information is located in the last section of the report thatperfdumpreturns.
For more information, seeEnabling StatisticsandUsing Performance Buckets.
Note
You must include a period (.) before the extension you defined in themime.typesfile (in this case,.perf).
The report contains the following information:
- Average, Total, and Percent columns give data for each requested statistic.
- Request Processing Time is the total time required by the server to process all the requests it has received so far.
- Number of Requests is the total number of requests for the function.
- Number of Invocations is the total number of times that the function was invoked. This differs from the number of requests in that a function could be called multiple times while processing one request. The percentage column for this row is calculated in reference to the total number of invocations for all the buckets.
- Latency is the time in seconds iPlanet Web Server takes to prepare for calling the function.
- Function Processing Time is the time in seconds iPlanet Web Server spent inside the function. The percentage of Function Processing Time and Total Response Time is calculated with reference to the total Request processing time.
- Total Response Time is the sum in seconds of Function Processing Time and Latency.
Configuring the File Cache
The iPlanet Web Server uses a file cache to serve static information faster. In the previous version of the server, there was also an accelerator cache that routed requests to the file cache, but the accelerator cache is no longer used. The file cache contains information about files and static file content. The file cache also caches information that is used to speed up processing of server-parsed HTML.
The file cache is turned on by default. The file cache settings are contained in a file callednsfc.conf. You can use the Server Manager to change the file cache settings.
To configure the file cache, follow these steps:
- From the Server Manager, select the Preferences tab.
- Select File Cache Configuration.
- Check Enable File Cache, if not already selected.
- Choose whether or not to transmit files.
- When you enable Transmit File, the server caches open file descriptors for files in the file cache, rather than the file contents, andPR_TransmitFileis used to send the file contents to a client. When Transmit File is enabled, 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, Transmit File is enabled on Windows NT, and not enabled on Unix. On Unix, only enable Transmit File for platforms that have native OS support forPR_TransmitFile, which currently includes HP-UX and AIX. It is not recommended for other Unix/Linux platforms.
- Enter a size for the hash table.
- The default size is twice the maximum number of files plus 1. For example, if your maximum number of files is set to 1024, the default hash table size is 2049.
- Enter a maximum age in seconds for a valid cache entry.
- By default, this is set to 30.
- This setting controls how long cached information will continue to be used once a file has been cached. An entry older thanMaxAgeis replaced by a new entry for the same file, if the same file is referenced through the cache.
- Set the maximum age 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, you could set the maximum age to 21600 seconds (6 hours). Otherwise, consider setting the maximum age to the longest time you are willing to serve the previous version of a content file after the file has been modified.
- Enter the Maximum Number of Files to be cached.
- (Unix /Linux only) Enter medium and small file size limits in bytes.
- By default, the Medium File Size Limit is set to 525000 (525 KB).
- By default, Small File Size Limit is set to 2048.
- The cache treats small, medium, and large files differently. The contents of medium files are cached by mapping the file into virtual memory (currently only on Unix/Linux platforms). The contents of "small" files are cached by allocating heap space and reading the file into it. The contents of "large" files (larger than "medium") are not cached, although information about large files is cached.
- The advantage 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 Small File Size Limit is typically a slightly lower value than the VM page size.
- (Unix /Linux only) Set the medium and small file space.
- The medium file space is the size in bytes of the virtual memory used to map all medium sized files. By default, this is set to 10000000 (10MB).
- The small file space is the size of heap space in bytes used for the cache, including heap space used to cache small files. By default, this is set to 1MB for Unix/Linux.
- Click OK.
- Click Apply.
- Select Apply Changes to restart your server.
Using the nocache Parameter
You can use the parameternocachefor the Service functionsend-fileto 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 by editingobj.conf.
In the above example, the server does not cache static files from/export/mydir/when requested by the URL prefix/myurl.
Monitoring the File Cache with the Server Manager
To view the file cache statistics the Server Manager, follow these steps:
- From the Server Manager, select Monitor.
- Select Monitor Current Activity.
- If you have not yet enabled statistics, when the Monitor Statistics of a Web Server page appears, click OK.
- Choose a Refresh Interval.
- From the drop-down list of statistics to be displayed, choose Cache.
- Click OK.
- The cache statistics appear, refreshed every 5-15 seconds, depending upon the refresh interval you chose.
File Cache Dynamic Control and Monitoring
You can add an object toobj.confto dynamically monitor and control thensfc.conffile cache while the server is running. To do this:
The following is an example of the information you receive when you access the URI:
You can include a query string when you access the "/nsfc" URI. The following values are recognized:
- ?list- Lists the files in the cache.
- ?refresh=n- Causes the client to reload the page everynseconds.
- ?restart- Causes the cache to be shut down and then restarted.
- ?start- Starts the cache.
- ?stop- Shuts down the cache.
- C - File contents are cached.
- D - Cache entry is marked for delete.
- E -PR_GetFileInfo()returned an error for this file.
- I - File information (size, modify date, etc.) is cached.
- M - File contents are mapped into virtual memory.
- O - File descriptor is cached (whenTransmitFileis set to true).
- P - File has associated private data (should appear onshtmlfiles).
- T - Cache entry has a temporary file.
- W - Cache entry is locked for write access.
Tuning the ACL User Cache
The ACL user cache is on by default. Because of the default size of the cache (200 entries), the ACL user cache can be a bottleneck, or can simply not serve its purpose on a site with heavy traffic. On a busy site 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 theACLUserCacheSizedirective inmagnus.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 theACLGroupCacheSizedirective.
ACL User Cache Directives
To adjust the ACL user cache values you will need to manually add the following directives to yourmagnus.conffile:
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 againstACLCacheLifetime. The entry is not used if its age is greater than or equal to theACLCacheLifetime. 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 ACL User Cache Settings
WithLogVerboseyou can verify that the ACL user cache settings are being used. WhenLogVerboseis running you should expect to see these messages in your errors log when the server starts:
Tuning
You can turnLogVerboseon by:
- Editing theLogVerboseparameter inmagnus.conf
- Setting or changing theLogVerbosevalue to on in the Magnus Editor of the Server Manager
Do not turn onLogVerboseon a production server, because doing so degrades performance and increases the size of your error logs considerably.
Using Quality of Service
The quality of service features let you limit the amount of bandwidth and number of connections for a server instance, class of virtual servers, or individual virtual server. You can set these performance limits, track them, and optionally enforce them.
For more information, see "Using Quality of Service" on page 213 of theAdministrator's Guide.
Using Load Balancing
Load balancing is dividing the amount of server traffic between two or more computers so that more work gets done in the same amount of time and all online users will generally be served faster.
You can use a third party plug-in, for example the "Resonate Command Module for iPlanet Web Server", to provide load balancing capabilities. Other companies may also provide load balancing solutions that work with iPlanet Web Server. For more information, contact the load balancing plug-in provider.
Using libresonate
You can use the load balancing plug-in libresonate to allow your server to execute a program when certain thread load conditions are met, so a load distribution product on the front-end can redistribute the load.
There are two methods that you can use to trigger the load balancer to increase or decrease load:
Standard.Base load decisions on the number of queued requests. This is a passive approach. By letting the queue fill up you are already delaying some requests. In this case you want theHighThresholdto be a low value andLowThresholdto be a high value.
Aggressive.Base load decisions on the number of active threads in the pool. This is designed to more tightly control the requests so that you would reduce the load before requests get queued.
Library configuration
In order to enable the plug-in, you need to modifymagnus.confmanually. This should look something like this:
Init fn="load-modules" funcs="init-resonate" shlib="server_root/bin/https/lib/libresonate.so"
Init fn="init-resonate" ThreadPool="sleep" EventExePath="/tools/ns/bin/perl5" LateInit="yes" CmdLow="/usr/netscape/ent41/plugins/loadbal/CmdLow.pl" CmdHigh="/usr/netscape/ent41/plugins/loadbal/CmdHigh.pl"
Theinit-resonatefunction can take the following parameters:
Note
You must specifyLateInit="yes"when loading this module. This is because the module creates a monitoring thread and this monitoring thread needs to start afterns-httpdhas started.
If you setLogVerbose oninmagnus.conf, the error log contains information on how the plug-in is configured and when it is invoked.
A sample of the information in the error log is shown below:
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin watching thread pool sleep
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin aggressive setting is FALSE
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin poll time set to 2000
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin HighThreshold set to 5
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin LowThreshold set to 1
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin event executable path set to /tools/ns/bin/perl5
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin low command set to /usr/netscape/ent41/plugins/loadbal/CmdLow.pl
[12/Jun/2000:09:36:35] verbose (20685): Resonate plugin high command set to /usr/netscape/ent41/plugins/loadbal/CmdHigh.pl
This is what will the log entries will look like whenLogVerbose onis set and the plugin is activated:
[12/Jun/2000:09:40:12] verbose (20699): Resonate plugin reducing load.
[12/Jun/2000:09:40:14] verbose (20699): Resonate plugin reducing load.
[12/Jun/2000:09:40:16] verbose (20699): Resonate plugin reducing load.
[12/Jun/2000:09:40:18] verbose (20699): Resonate plugin reducing load.
[12/Jun/2000:09:40:20] verbose (20699): Resonate plugin reducing load.
[12/Jun/2000:09:40:30] verbose (20699): Resonate plugin increasing load.
Testing
To test the load balancer, you can create an NSAPI plug-in that prints an HTML page and then callssleep()for a period to simulate execution time. This way you can build up a simulated load on the server and ensure that the load balancer commands are working properly.
To configure the sample program, follow these steps:
- Add a newmine.typeso this isn't run for every request by modifyingconfig/mime.typesand adding:
- Create a file in your doc-ument root directory with the extension of.sleep.
- Load the module into the server by editingmagnus.conf.
- Init fn="load-modules" funcs="dosleep" shlib="/usr/netscape/ent41/plugins/nsapi/examples/dosleep.so" pool="sleep"
- In the example above, you are changingshlibto the location of the library, and settingpoolto the name of the thread pool you defined earlier:
- Add this Service line where the others are found (note that order is not important):
- Service method="(GET|HEAD)" fn="dosleep" duration="10" type="magnus-internal/sleep"
- The argument duration tells the server how long to sleep for each request in seconds.
- Restart your server.
Sample
Below is a sampledosleep.c:
#ifdef XP_WIN32
#define NSAPI_PUBLIC __declspec(dllexport)
#else /* !XP_WIN32 */
#define NSAPI_PUBLIC
#endif /* !XP_WIN32 */
#include "nsapi.h"
#define BUFFER_SIZE 1024
#ifdef __cplusplus
extern "C"
#endif
NSAPI_PUBLIC int dosleep(pblock *pb, Session *sn, Request *rq)
{
char buf[BUFFER_SIZE];
int length, duration;
char *dur = pblock_findval("duration", pb);
if (!dur) {
log_error(LOG_WARN, "dosleep", sn, rq, "Value for duration is not set.");
return REQ_ABORTED;
}
duration = atoi(dur);
/* We need to get rid of the internal content type. */
param_free(pblock_remove("content-type", rq->srvhdrs));
pblock_nvinsert("content-type", "text/html", rq->srvhdrs);
protocol_status(sn, rq, PROTOCOL_OK, NULL);
/* get ready to send page */
protocol_start_response(sn, rq);
/* fill the buffer with our message */
length = util_snprintf(buf, BUFFER_SIZE, "<title>%s</title><h1>%s</h1>\n", "Sleeping", "Sleeping");
length += util_snprintf(&buf[length], BUFFER_SIZE - length, "Sample NSAPI that is sleeping for %d seconds...\n", duration);
/* write the message to the client */
if (net_write(sn->csd, buf, length) == IO_ERROR)
{
return REQ_EXIT;
}
sleep(duration);
return REQ_PROCEED;
}
Threads, Processes, and Connections
In iPlanet Web Server 6.0, acceptor threads on a listen socket accept connections and put them onto a connection queue. Session threads then pick up connections from the queue and service the requests. The session threads post more session threads if required at the end of the request. The policy for adding new threads is based on the connection queue state:
- Each time a new connection is returned, the number of connections waiting in the queue (the backlog of connections) is compared to the number of session threads already created. If it is greater than the number of threads, more threads are scheduled to be added the next time a request completes.
- The previous backlog is tracked, so that if it is seen to be increasing over time, and if the increase is greater than theThreadIncrementvalue, and the number of session threads minus the backlog is less than theThreadIncrementvalue, then anotherThreadIncrementnumber of threads are scheduled to be added.
- The process of adding new session threads is strictly limited by theRqThrottlevalue.
- To avoid creating too many threads when the backlog increases suddenly (such as the startup of benchmark loads), the decision whether more threads are needed is made only once every 16 or 32 times a connection is made based on how many session threads already exist.