| Previous Contents Index DocHome Next |
| iPlanet Web Proxy Server 3.6 Administrator's Guide - Unix Version |
Chapter 15 Tuning Server Performance
This chapter explains how to tune your server's performance using the online forms as well as the configuration files. It also provides recommendations for performance tuning. By tuning your server's performance parameters, you can optimize the speed and efficiency of your proxy server.
Using Timeouts Effectively
Timeouts have a significant impact on server performance. Setting the optimal timeout for your proxy server will help to conserve network resources.
Read Timeout
The read timeout is the number of seconds the proxy server will wait for an incoming request. The default value for this timeout is 60 seconds. Setting the timeout a few seconds shorter will allow proxy resources to be released faster if the connection stays idle (e.g., if you telnet to the proxy port and let it just sit there).You can view or modify the read timeout on the Proxy Tuning form. You can access this form by choosing System Setting|Tuning from the Server Manager.
Proxy Timeout
The proxy timeout tells the server how long to wait before aborting an idle connection. A high proxy timeout value commits a valuable proxy process to a potentially dead client for a long time. A low timeout value will abort CGI scripts that take a long time to produce their results, i.e., a database query gateway.To determine the best proxy timeout for your server, you should consider these issues:
Will your proxy be handling many database queries or CGI scripts?
If you answered yes to the above questions, then you may decide to set a high proxy timeout value. The highest proxy timeout value recommendedis 1 hour. You can view or modify the proxy timeout value on the System Specifics form. You can access this form by choosing Server Preferences|System Specifics from the Server Manager.Will your proxy server be handling a small enough amount of requests that it can spare a process at any given time?
Timeout After Interrupt
The timeout after interrupt value tells the proxy how much time it has to continue writing a cache file after a client has aborted the transaction. In other words, if the proxy server has almost finished caching a document and the client aborts the connection, the proxy can continue caching the document until it reaches the timeout after interrupt value.To determine the best timeout after interrupt value for your proxy server, use sitemon. If sitemon reports that the proxy server is using too much of its process pool, you should reduce your timeout after interrupt accordingly. The highest recommended timeout after interrupt value is 5 minutes.
You can set the timeout after interrupt value on the System Specifics form. You can access this form by choosing Server Preferences|System Specifics from the Server Manager.
Keep-Alive Timeout
The keep-alive timeout is the number of seconds the proxy server will wait for the next request from a keep-alive connection. The default value for this timeout is 5 seconds. Shorter timeouts let the proxy release resources that are tied up by idle keep-alive connections. Longer timeouts will make keep-alive more effective, but can tie up valuable proxy resources, and thus, bog down the server. You should not use the keep-alive feature because it can easily cause problems when the entire process pool is tied up by idle keep-alive connections. This problem can occur quickly - especially with clients that open multiple simultaneous connections, such as Navigator, which by default, opens 4 connections.You can view or modify the keep-alive timeout on the Proxy Tuning form. You can access this form by choosing Server Preferences|Tuning from the Server Manager.
Global Netlib Timeout
The global netlib timeout is the absolute maximum number of seconds that the proxy will wait for any HTTP, FTP, Gopher or HTTPS retrieval. The default value for this timeout is 10800 seconds (3 hours). You may want to increase this number if you are using a modem to download large applications.You can view or modify the global netlib timeout on the Proxy Tuning form. You can access this form by choosing System Setting|Tuning from the Server Manager.
Stall Timeout Override
You should not change this value under any circumstances.
Controlling Up-to-Date Checks
For the sake of performance, it is not recommended that you configure your proxy server to check if a cached document is up-to-date each time that document is requested. Frequent up-to-date checks may unnecessarily consume network resources. Therefore, you may not want to have your server perform up-to-date checks all of the time. To improve the server's performance while ensuring that a document is up-to-date, choose a reasonable document lifetime in conjunction with the last-modified factor. For more information on the last-modified factor, see Setting the Last-modified Factor.You should set an up-to-date check range between 8 and 24 hours.
For more information on controlling up to date checks, see Chapter 9, "Caching."
Setting the Last-modified Factor
The last-modified factor is a fraction which is multiplied by the interval between a document's last modification and the time that the last up-to-date check was performed on the document. The resulting number is compared with the time since the last up-to-date check. If the number is smaller than the time interval, the document is not expired. The last-modified factor allows you to ensure that recently changed documents are checked more often than old documents.You should set a last-modified factor between 0.1 and 0.2. For more information on setting the last-modified factor, see Chapter 9, "Caching."
Using DNS Effectively
DNS (Domain Name Service) is the system used to associate standard IP addresses with host names. This system can tie up valuable proxy resources if not configured wisely. To optimize the performance of DNS:
Enable DNS Caching
Do not log client DNS names
- You can enable DNS Caching by choosing Server Preferences|DNS Caching from the Server Manager and selecting the enabled radio button for DNS caching. For more information on DNS caching, see "Understanding DNS Caching" on page 60.
- You can specify whether or not your DNS cache file is visible with the DNS cache file visible value on the Proxy Tuning form. By default, the cache file is invisible. You can view or modify the DNS cache file visible value on the Proxy Tuning form. You can access this form by choosing Sever Preferences|Tuning from the Server Manager.
Log only client IP addresses
- You can disable client DNS name logging by choosing Server Status|Log Preferences from the Server Manager and deselecting the radio button for recording client domain names. For more information on logging client domain names, see "Setting Access Log Preferences" on page 198.
Disable reverse DNS
- You can enable client IP address logging by choosing Server Status|Log Preferences from the Server Manager and selecting the radio button for recording client IP addresses. For more information on logging client IP addresses, see "Setting Access Log Preferences" on page 198.
Avoid access control based on client host names.
- Reverse DNS translates an IP address into a host name. You can disable reverse DNS by choosing Server Preferences|System Specifics from the Server Manager and selecting the "No" radio button for Enable DNS.
- Use clients' IP addresses instead, if possible. You can configure access control by choosing Server Preferences|Restrict Access from the Server Manager. For more information on access control, see Chapter 5, "Controlling Access to Your Server
Determining the Number of Processes
On the UNIX platform, administrators must specify the number of processes that will be pre-forked on the server. Pre-forking enhances the performance of the proxy server because the number of processes limits the concurrent requests the proxy can handle simultaneously. The chart below indicates how many processes might be necessary for a certain number of users.
Users
Processes
Memory (MB)
Swap (MB)
While you can estimate the number of processes you will need, it is important that you properly scale the proxy server to meet your load in the peak periods. Typically, if you have a need to tune the server, your current process allocation is insufficient. Sitemon will usually display 100% processes-in-use, but this does not show you the number of clients that are queued by the operating system.
You can estimate the number of clients in waiting by using netstat. Information on the correct command line options to list all TCP sessions can be found in your system's manual page for netstat. From this snapshot, count up all connections to port 8080, or your designated proxy port, that are in TCP states between SYN_RECVD and CLOSE_WAIT, including ESTABLISHED. Your system may vary slightly, so check your documentation. The count you now have should be a snapshot of accepted connections, those that have been established, plus any that have been queued by the system because there are not enough processes available.
Run the log analyzer for a few days to get a good distribution of load on your server. The pstats utility located in extras/proxy/pstats is the fastest way to calculate these statistics. Run the utility when your server has a moderate load. This means that your process utilization is between 60% and 80%. It is important to consider that in peak times, under extreme load, connections will take longer than expected due to things like thrashing, swapping, or OS listen queue overload. You want to make sure that your system is not swapping, so this baseline configuration should not have more processes than can fit in RAM. For this time period, look at your average transaction time from the flex analyzer. Add 10% to this estimate if you want to be conservative.
The section titled "Processes" on page 55 contains a chart of the suggested number of processes given as a function of average number of new requests per second versus average number of seconds of service time per request. You should refer to this section for recommendations on determining the optimum number of processes for your server.
For more information on setting the number of processes, see "Processes" on page 55.
Disabling Keep-Alives
HTTP Keep-Alives are a TCP/IP feature that keeps a connection open after the request is complete so that the client can quickly reuse the open connection. For optimal server performance, it is wise to disable HTTP keep-alives.For more information on enabling and disabling keep-alives, see "Enabling HTTP Keep-Alive" on page 62.
Using SOCKS Effectively
Using the socks5.conf file, you can determine the number of worker and accept threads your SOCKS server uses. These numbers will influence the performance of your SOCKS server.
Worker Threads
Worker threads perform authentication and access control for new SOCKS connections. If the SOCKS request is granted, the worker thread passes the connection to the I/O thread which passes the data outside the firewall.If the SOCKS server is too slow, you should increase the number of worker threads. If it is unstable, decrease the number of worker threads. When changing the number of worker threads, you should start at the default number and increase or decrease as necessary.
The default number of worker threads is 40, and the typical number of worker threads falls between 10 and 150. The absolute maximum number of worker threads is 512. However, having more than 150 tends to be wasteful and unstable.
Accept Threads
Accept threads sit on the SOCKS port listening for new SOCKS requests. They pick up the connections to the SOCKS port and hand each new connection to a worker thread.If the SOCKS server is dropping connections, you should increase the number of accept threads. If it is unstable, decrease the number of accept threads. When changing the number of accept threads, you should start at the default number and increase or decrease as necessary.
The default number of accept threads is 1, and the typical number of accept threads falls between 1 and 10. The absolute maximum number of accept threads is 512, however, having more than 60 tends to be wasteful and unstable.
Tuning FTP Listing Width
You may want to modify the width of FTP listings to better suit your needs. Increasing listing width allows longer file names and thus reduces filename truncation. The default width is 80 characters.You can modify the FTP listing width on the Proxy Tuning form. You can access this form by choosing Server Preferences|Tuning from the Server Manager.
The FTP listing width should only be changed if you are instructed to do so by iPlanet Technical Support. The default values should not be changed unless there is a problem with the default behavior.
Using the Cache Effectively
You can ensure that you are effectively using your cache by architecting the cache wisely and by determining the best cache tuning settings for your cache.
Optimizing Cache Architecture
You can improve the performance of your server by architecting your cache wisely. Some suggestions to keep in mind when architecting your cache are:Proper cache setup is critical to the performance of your proxy server. The most important rule to remember when laying out your proxy cache is to distribute the load. Caches should be set up with approximately 1 GB per partition and should be spread across multiple disks and multiple disk controllers. This type of arrangement will provide faster file creation and retrieval than is possible with a single, larger cache. For more information on setting up your cache, see Chapter 9, "Caching
The Cache Batch Update feature in iPlanet Web Proxy Server allows you to proactively download content from a specified web site or perform scheduled up-to-date checks on documents already in the cache. This gives you the ability to cache content in large quantities at times when traffic on the server is low. Use batch updates to download the most commonly accessed sites at the end of each business day for quick access the following morning. You can use the log files to help determine which sites are frequently accessed. For more information on batch updates, see "Using Cache Batch Updates" on page 131.
Tuning the Cache
You may need to tune your cache to improve its performance. You can view or modify all of the following settings on the Cache Tuning form.
Add'l Cch-status Values
The add'l cch-status values setting determines whether to use additional cache status values in the access log. You can log these additional cache status values:DO-NOT-CACHE - pre-determined non-cacheable (by configuration)
NON-CACHEABLE - post-determined non-cacheable (by response fields)
NOT-IN-CACHE - with disconnected operation, cache miss
Currently, the add'l cch-status values logging option causes all UP-TO-DATE log entries to be reverted to NON-CACHEABLE. For this reason, tune to "original".
You can enable add'l cch-status values on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Mmap on Initial Writes
The mmap on initial writes value determines whether to use mmap or lseek+write to create the initial CIF header. By default, this value is off. You should not change this value.You can view the mmap on initial writes setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
You should not change the mmap on initial writes value.
Mmap on Cache Updates
The mmap on cache updates value determines whether to use memory mapped I/O when sending data from the cache and updating cache files. By default, this value is on.You can view or modify mmap on cache updates on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Use Shared Memory I/O
The use shared memory I/O value determines whether shared memory is enabled. The child processes communicate with the cache monitor and cache manager via either an interprocess pipe/socket, or shared memory. The shared memory based I/O is faster. By default, shared memory I/O is enabled.You can view or modify use shared memory I/O on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Notify Num Changes
The notify num changes value is used only when shared memory I/O is enabled.Notify num changes determines the number of changes after which the cache monitor is notified about changes made by that child process. More frequent notifications keep the cache monitor up-to-date on the status and size of the cache, but create more work for the cache monitor. The valid range for notify num changes is 1 to 500, and the default value is 10.
You can view or modify the notify num changes setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Notify Blk Limit
The notify blk limit value is used only when shared memory I/O is enabled.Notify blk limit determines the number of blocks that cache size usage has changed as a result of a single child process until the cache monitor is notified by that child. Smaller notification limits keep the cache monitor up-to-date on the status and size of the cache, but create more work for the cache monitor. The valid range for notify num changes is 1 to 10000 (0.5K to 5MB), and the default value is 100 (50K).
You can view or modify the notify blk limit setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
C-mon Tick Interval
You should not change this value under any circumstances.
Max Mmap Size
The max mmap size is the maximum number of kilobytes memory-mapped at once by a single process. Files larger than the max mmap size will be memory-mapped in portions of this size. By default, the max mmap size is 256K.The max mmap size must be at least 16, and it must be a multiple of page size, which is often four.
You can view or modify the max mmap size setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Min Sync Interval
The min sync interval specifies the amount of time the cache manager waits before traversing the entire cache to find out the actual cache size. The cache monitor attempts to maintain current information about the size of each cache section. However, the information may get skewed by unexpected software shutdowns, system crashes, power failures, etc. Another reason for skew is that a server shutdown will lose unnotified changes to the cache in child processes. Because of these skews, the cache manager periodically traverses the entire cache to determine the actual cache size.The valid range for min-sync-interval is 1800 seconds(1/2 hour) to 604800 seconds (1 week), and the default is 86400 seconds (24 hours).
You can view or modify the min sync interval on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
The min sync interval should only be changed if you are instructed to do so by iPlanet Technical Support. The default values should not be changed unless there is a problem with the default behavior.
Notify Blk Chunk/Proc
Each server child process notifies the cache monitor about how much new cache space it has taken up (or released) by creating new cache files or updating old ones. To avoid message overflow, these notifications are not sent for every cache operation, but rather each process waits until it has reached a certain threshold before notifying the cache monitor about its activities. The notify blk chunk/proc variable controls the threshold which triggers each child process to report their cache usage to the cache monitor. The units are in "blocks." A block is always 512 bytes (0.5 KB), regardless of the operating system filesystem block size.The notify blk chunk/proc value is multiplied by the value of the MaxProcs directive. Therefore, the effect of having a higher MaxProcs setting is that child processes will buffer more cache change messages before they notify the cache monitor about them. This effect avoids message overflow on systems with a high load (large MaxProcs), and allows small caches to maintain more accurate size information (small MaxProcs).
The valid range for notify blk chunk/proc is 0 to 2000 (1MB per process), and the default value is 67 (33KB per process).
For example, the default setting 67 (33K) on a system with 64 processes means that each process buffers cache activity notifications until it has reserved 64 * 33K = 2.1MB of the cache. This means that a proxy shutdown can cause an average skew of 67MB in cache size. This condition gets corrected during the next cache size sync (see min-sync-interval). This behavior is usually acceptable on high-end systems, with greater than 2GB of cache space.
You can view or modify the notify blk chunk /proc setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Fs Full Retry After
When a server child process fails to write to disk and the error code is ENOSPC (No space left on device), the process stops writing data to that cache partition, allowing time for the garbage collector to correct the situation. The fs full retry after variable controls how many cache write requests should be skipped before the proxy attempts a write operation again.The valid range for fs full retry after is 1 (retry immediately) to 1024 (practically don't retry), and the default value is 50.
You can view or modify the fs full retry after setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Update After Percent
The cache monitor continuously receives messages from server child processes about how much new cache space they have used up (see variable notify-block-chunk-per-proc). To conserve CPU time, the cache monitor doesn't update its partition table and evaluate garbage collection needs after every such message. Instead, it waits until there is big enough percentage change in size. The update after percent value controls that percentage.The valid range for update after percent is 0 (every time) to 100 (after size doubles), and the default value is 1.
You can view or modify the update after percent setting on the Cache Tuning form. You can access this form by choosing Caching|Tune Cache from the Server Manager.
Sync Dump Ticks
You should not change this value under any circumstances.
Byte-Ranges
The byte-ranges value determines whether or not the proxy is allowed to generate byte-range responses from the cache. By default, this feature is disabled. This version of the proxy supports single byte-ranges only. If Adobe Acrobat plugin is not in use, enabling this feature will allow faster truncated document/image retrievals by Navigator clients.
Single Accept
You should not change this value under any circumstances.
Tuning the Garbage Collector
Garbage Collection is a resource-intensive process. Therefore, you may need to tune some garbage collection settings to improve its performance. You can view and modify all of the following garbage collection settings on the GC Tuning form.
Gc URL DB Interval
The gc URL db interval controls how often the URL database is cleaned of old URLs and how often it is checked for consistency.The valid range for the gc URL db interval is 1800 sec (30 minutes) to 604800 (1 week), and the default value is 79200 seconds (22 hours).
You can view or modify the gc URL db interval on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Nap Length
The garbage collector takes "naps" every so often so that it does not use all the CPU from other processes. The gc nap length is the amount of time that the garbage collector sleeps during one nap.The frequency of these naps is controlled by two variables: hard gc nap count and soft gc nap count.
The valid range for gc nap length is 0 (no naps) to 120 (2 minutes), and the default is 1 second.
You can view or modify the gc nap length on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
The gc nap length should only be changed if you are instructed to do so by iPlanet Technical Support. The default values should not be changed unless there is a problem with the default behavior.
Hard Gc Nap Count
There are two types of garbage collection: hard and soft. The hard garbage collector traverses the entire cache section and finds all the files individually, picking the ones to delete, and then generates lists of files in the cache ordered by their relative value. These lists are then used by the soft garbage collector to delete files without traversing the entire cache structure.Hard garbage collection is more resource intensive than soft garbage collection, but it is required every time soft garbage collection runs out of the lists generated by hard garbage collection.
The hard gc nap count value specifies how many naps hard garbage collector takes during the garbage collection cycle of a single cache section. There are 64 subdirectories on each cache section, and naps can be taken between directories only. This means that there can be at most 64 naps. The number of naps should be a power of two.
The length of each nap is controlled by the variable gc nap length.
The valid values for hard gc nap count are: 0 (no sleeps), 1, 2, 4, 8, 16, 32, and 64 (max). The default value is 16 (sleep after every 4 directories).
You can view or modify the hard gc nap count on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
The hard gc nap count should only be changed if you are instructed to do so by iPlanet Technical Support. The default values should not be changed unless there is a problem with the default behavior.
Soft Gc Nap Count
The soft garbage collector simply reads a list of cache files from a set of files produced by the hard garbage collector. It still looks up the file using the stat() system call to find out if there have been subsequent accesses to the cache file during the last garbage collection, which suggests that the cache file is being (or may be) actively used, and should not be removed. The soft gc nap count value specifies how many naps the soft garbage collector takes during the garbage collection cycle.The length of each nap is controlled by the variable gc nap length.
The valid range for soft gc nap count is 0 (no naps) to 1000 naps, and the default value is 20 naps.
You can view or modify the soft gc nap count on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
The soft gc nap count should only be changed if you are instructed to do so by iPlanet Technical Support. The default values should not be changed unless there is a problem with the default behavior.
Hard Gc Max Entries
Hard gc max entries identifies the number of cache entry slots allocated during one pass for garbage collection. One "pass" in garbage collection is defined by the variable gc dir chunk which is the number of subdirectories within a cache section that will be processed in one pass.This number should be of the same order as the number of files in a typical chunk of directories. As an example, a typical subdirectory in a cache section has 100-200 files. If the gc dir chunk variable is set to 8, then the "hard gc max entries" value should be set to around 800-1600.
A single cache entry is about 32 bytes, so every 1000 entries in this variable means 32KB pool allocation.
A valid range for hard gc max entries is 100(3K) to 5000 (160K), and the default value is 500 (16K).
You can view or modify the hard gc max entries setting on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Dir Chunk
The gc dir chunk variable controls the sample size for the LRU algorithm. Basically, this means it controls how many subdirectories under each cache section are processed by the garbage collector in one pass. Because a larger gc dir chunk value causes the proxy to process more files simultaneously, more memory is required. Larger gc dir chunk values also cause the garbage collector to be slower and more CPU intensive. The smaller the gc dir chunk value is, the lighter-weight garbage collection becomes. However, the sample size for the LRU algorithm becomes smaller.The gc dir chunk value must be a power of two.
Valid values for gc dir chunk are: 1 (single directory), 2, 4, 8, 16, 32, and 64 (all directories at once). The default value is 8 directories.
You can view or modify the gc dir chunk setting on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Hi Margin Percent
The gc hi margin percent variable controls the percentage of the maximum cache size that, when reached, triggers garbage collection.This value must be higher than the value for gc lo margin percent.
The valid range for gc hi margin percent is 10 to 100 percent (trigger garbage collection when full). The default value is 80 percent (trigger gc when 80% full).
You can view or modify the gc hi margin percent on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Lo Margin Percent
The gc lo margin percent variable controls the percentage of the maximum cache size that the garbage collector targets.This value must be lower than the value for gc-hi-margin-percent.
The valid range for gc lo margin percent is 5 to 100 percent. The default value is 70 percent (target at 70% full cache after gc).
You can view or modify the gc lo margin percent on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Extra Margin Percent
If the garbage collection is triggered by a reason other than the partition's size getting close to the maximum allowed size (see gc-hi-margin-percent), the garbage collector will use the percentage set by the gc extra margin percent variable to determine the fraction of the cache to remove.The valid range for gc extra margin percent is 0 to 100 percent, and the default value is 30 percent (remove 30% of existing cache files).
You can view or modify the gc extra margin percent on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Gc Leave Fs Full Percent
The gc leave fs full percent value determines the percentage of the cache partition size below which garbage collection will not go. This value prevents the garbage collector from removing all files from the cache if some other application is hogging the disk space.The valid range for gc leave fs full percent is 0 (allow total removal) to 100 percent (remove nothing). The default value is 60 percent (allow the cache size to shrink to 60% of current).
You can view or modify the gc leave fs full percent on the GC Tuning form. You can access this form by choosing Caching|Tune GC from the Server Manager.
Previous Contents Index DocHome Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated September 27, 2001