Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Web Proxy Server 4.0.1 Administration Guide 

Appendix B
Tuning Server Performance

Many elements impact performance in your Proxy Server environment, including the proxy client, the Proxy Server, the origin server, and the network. This appendix describes adjustments you can make that may improve Proxy Server performance.

This appendix contains the following sections:


Caution

This appendix is for advanced administrators ONLY. Be very careful when tuning your server, and always back up configuration files before making any changes.



General Performance Considerations

This section describes general areas to consider when analyzing Proxy Server performance.

This section contains the following topics:

Access Logging

Disabling access logging can increase the performance of your Proxy Server. This comes at a cost, however, because you lose visibility as to who is accessing the Proxy Server and what pages they are requesting.

You can disable Proxy Server access logging by commenting out the following directives in the obj.conf file:

Init fn="flex-init" access="$accesslog" format.access="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%"
...
AddLog fn="flex-log" name="access"

ACL Cache Tuning

By default the Proxy Server caches user and group authentication results in the ACL user cache. You can control the amount of time the ACL user cache is valid with the ACLCacheLifetime directive in the magnus.conf file. 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 for the ACLCacheLifetime is 120 seconds, which means that the Proxy Server may be out of sync with the LDAP server for as long as two minutes. Setting the value to 0 (zero) turns the cache off and forces the Proxy Server to query the LDAP server each time a user authenticates. This will have a negative impact on the performance of your Proxy Server when implementing access control. If you set a large ACLCacheLifetime value, however, you may need to restart Proxy Server every time you make changes to the LDAP entries, as this will force the Proxy Server to query the LDAP server. Set a large value only if your LDAP directory is not likely to change often.

The ACLUserCacheSize is a magnus.conf parameter that configures the maximum number of entries that can be held in the cache. The default value is 200. New entries are added to the beginning of the list, and entries at the end of this list are recycled to permit new entries when the cache reaches its maximum size.

You can also set the maximum number of group memberships that can be cached per user entry with the ACLGroupCacheSize parameter. The default value is 4. Unfortunately, non-membership of a user in a group is not cached, and will result in several LDAP directory accesses on every request.

Buffer Size

You can specify the size of the send buffer (SndBufSize) and the receiving buffer (RcvBufSize) at the server’s sockets. These parameters are configurable in the magnus.conf file, and the recommended values vary between various UNIX and Linux operating systems. Refer to the operating system’s documentation to properly set these parameters.

Connection Timeout

You can specify the number of seconds the server waits for data to arrive from the client before closing the connection by using the AcceptTimeout directive in the magnus.conf file. If data does not arrive before the timeout expires, the connection is closed. This is set to 30 seconds by default. Under most circumstances, you do not need to change this setting. You can free up threads by setting this to less than the default, but you might also disconnect users with slower connections.

Errors Log Level

Increasing the loglevel attribute in the LOG tag of the server.xml file causes the server to generate and store more information in the errors log. This does, however, come at a cost when writing entries to that file. Increase logging only while debugging a problem, and minimize logging when not in a troubleshooting mode.

Security Requirements

Enabling SSL increases the privacy and security of your Proxy Server, but also impacts performance as encryption and decryption of the packets causes overhead. You may want to consider offloading encryption and decryption processing to a hardware accelerator card.

Solaris File System Caching

The Proxy Server cache is not stored in random access memory. Accesses to files are made to the file system each time a document is extracted from cache. You may want to consider using Solaris’ file system caching to pre-load the Proxy Server cache into memory. References to cached files are then extracted from memory rather than from the file system.


Timeout Values

Timeouts have a significant impact on server performance. Setting the optimal timeout for the Proxy Server helps to conserve network resources.

There are two instance-specific SAFs (server application functions) and one global parameter that can be used to configure timeout values within the Proxy Server.

This section contains the following topics:

init-proxy SAF (obj.conf)

The init-proxy function initializes the Proxy Server’s internal settings. This function is called during the initialization of the Proxy Server, but should also be specified in the obj.conf file to ensure that the values are initialized properly.

The syntax of this function is as follows:

Init fn=init-proxy
  timeout=
seconds
  timeout-2=seconds

In the previous example, the following parameters have direct applicability to Proxy Server timeout settings for the init-proxy SAF:

http-client-config SAF (obj.conf)

The http-client-config function configures the Proxy Server’s HTTP client.

The syntax of this function is as follows:

Init fn=http-client-config
  keep-alive=(true|false)
  keep-alive-timeout=
seconds
  always-use-keep-alive=(true|false)
  protocol=
HTTP Protocol
  proxy-agent="Proxy-agent HTTP request header"

The settings are defined as follows:

KeepAliveTimeout (magnus.conf)

This parameter determines the maximum time (in seconds) that the server holds open HTTP keep-alive connections or persistent connections between the client and the Proxy Server. The default is 30 seconds. The connection times out if idle for more than 30 seconds. The maximum is 300 seconds (5 minutes).


Note

Timeout settings in the magnus.conf file apply to connections between the client and the Proxy Server. Timeout settings in the http-client-config SAF in the obj.conf file apply to connections between the Proxy Server and an origin server.



Up-to-Date Checks

Proxy Servers increase performance by serving documents out of a local cache rather than obtaining them from the origin server. One drawback to this methodology is the potential to provide documents that are out of date.

The Proxy Server can perform a check to determine whether a document is up to date, and then refresh the cached version if it is determined that the document is old. This up-to-date check should be performed only as necessary, as frequently checking documents can decrease the overall performance of the Proxy Server.

Up-to-date checking is configured on the Set Cache Specifics page of the Caching tab. The default is to check for a new document every two hours. This information is configured in the ObjectType directive with the max-uncheck parameter.

To improve the server’s performance while ensuring that a document is up-to-date, customize up-to-date checking by determining a reasonable document lifetime in conjunction with the last-modified factor, which is discussed below.

Last-Modified Factor

The last-modified factor is used to fine-tune document up-to-date processing. This factor helps determine the likelihood that a document will change based on the previous changes that have been noted.

The last-modified factor is a fraction between .02 and 1.0. It is multiplied by the interval between a document’s actual last modification and the time 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 has not expired. If, however, it is larger than the time interval, then the document has expired and a new version is obtained from the origin server.

The last-modified factor enables 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.


DNS Settings

DNS is the system used to associate standard IP addresses with host names. This system can tie up valuable Proxy Server resources if not configured wisely. To optimize performance, consider the following:


Number of Threads

The RqThrottle parameter in the magnus.conf file specifies the maximum number of simultaneous transactions the Proxy Server can handle. The default value is 128. Changes to this value can be used to throttle the server, minimizing latencies for transactions that are performed.

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 the maximum number of requests is already being processed. If the limit has been reached, the processing of new requests is deferred until the number of active requests drops below the maximum amount.

You can monitor the number of simultaneous requests by viewing the SessionCreationInfo portion of data generated by perfdump, or proxystats.xml data. From this information, you can determine the maximum number of simultaneous (peak) requests as compared to the total number (limit) of threads. The following information came from a perfdump output:

SessionCreationInfo:
------------------------
Active Sessions          1
Keep-Alive Sessions      0
Total Sessions Created   48/128

Active Sessions shows the number of sessions (request processing threads) currently servicing requests. Keep-Alive Sessions is similar to Active Sessions, but is specific to whether the client is requesting a keep-alive connection. Total Sessions Created shows both the number of sessions created and the maximum number of sessions allowed. These are the minimum and maximum values for the RqThrottle value.


Note

RqThrottleMin is the minimum number of threads the server initiates upon startup. The default value is 48. This parameter can also be set in the magnus.conf file, but does not appear by default.


Reaching the maximum number of configured threads is not necessarily undesirable, and you do not need to automatically increase the RqThrottle value if you see this. 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 your perfdump output on a regular basis and notice that total sessions created is often near the RqThrottle maximum, consider increasing your thread limits.

Suitable RqThrottle values range from 100 to 500, depending on the load.


Inbound Connection Pool

The inbound connection pool can be tuned using the KeepAlive* and related settings in magnus.conf, including the following:


Note

For more information about these parameters, see Chapter 2 of the Sun ONE Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide at:

http://docs.sun.com/source/817-6249/index.html


Outbound connection pool settings cannot be configured in this release of the Proxy Server.


FTP Listing Width

You might want to modify the width of FTP listings to better suit your needs. Increasing listing width allows longer file names and thus reduces file name truncation. The default width is 80 characters.

The FTP listing width can be modified by choosing the Tune Proxy link under the Preferences tab of the Server Manager.


Cache Architecture

Performance of your server can be improved by architecting your cache wisely. Suggestions to keep in mind when architecting your cache:

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 Gbyte per partition and should be spread across multiple disks and multiple disk controllers. This type of arrangement provides faster file creation and retrieval than is possible with a single, larger cache.


Cache Batch Update

The cache batch update feature enables you to pre-load files from a specified web site or perform an up-to-date check on documents already in the cache. This is typically initiated when the load on the Proxy Server is at its lowest. From the Cache Batch Updates form you can create, edit, and delete batches of URLs and enable and disable batch updating.

You can actively cache content (as opposed to on-demand), by specifying files to be batch updated. The Proxy Server enables you to perform an up-to-date check on several files currently in the cache, or pre-load multiple files in a particular web site.

At larger sites with a network of servers and proxies, administrators might want to use batch updating to pre-load a given area of the web. The batch process would perform a recursive descent across links in the document and cache the content locally. This function can be a burden on remote servers, so be careful when using it. Measures are taken to keep the process from performing recursion indefinitely, and the parameters in the bu.conf configuration file provides some control of this process.

Use the Proxy Server access logs to determine which sites are the most commonly active and perform a batch update on those sites to increase performance.


Garbage Collection

Garbage collection is the process of reviewing the Proxy Server cache and removing old (stale) files. Garbage collection is a resource-intensive process, therefore you may need to tune some garbage collection settings to improve its performance.

The following parameters provide the ability to fine-tune the garbage collection process. You can view or modify these parameters on the Tune Garbage Collection form, which is located by choosing Tune GC under the Caching tab of the Server Manager.

This section contains the following topics:

The gc hi margin percent Variable

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. The default value is 80 percent (trigger garbage collection when the cache is 80 percent full).

The gc lo margin percent Variable

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 percent full cache after garbage collection).

The gc extra margin percent Variable

If the garbage collection is triggered by a reason other than the partition’s size getting close to the maximum allowed size (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. The default value is 30 percent (remove 30 percent of existing cache files).

The gc leave fs full percent Variable

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 monopolizing 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 percent of current).


Solaris Performance Tuning

Various parameters in the Solaris kernel can be used to fine-tune Proxy Server performance. The following table lists some of those parameters.

Table B-1  Solaris Performance Tuning Parameters

Parameter

Scope

Default Value

Tuned Value

Comments

rlim_fd_max

/etc/system

1024

8192

Process open file descriptors limit. Should account for the expected load (for the associated sockets, files, and pipes, if any).

rlim_fd_cur

/etc/system

64

8192

 

sq_max_size

/etc/system

2

0

Controls streams driver queue size. Setting this to 0 makes it infinity, so the performance runs will not be hit by lack of buffer space. Set this on clients, too.

tcp_close_wait_interval

ndd/dev/tcp

240000

60000

Set this on clients, too.

tcp_conn_req_max_q

ndd/dev/tcp

128

1024

 

tcp_conn_req_max_q0

ndd/dev/tcp

1024

4096

 

tcp_ip_abort_interval

ndd/dev/tcp

480000

60000

 

tcp_keepalive_interval

ndd/dev/tcp

7200000

900000

For high traffic web sites, lower this value.

tcp_rexmit_interval_initial

ndd/dev/tcp

3000

3000

If retransmission is greater than 30-40%, increase this value.

tcp_rexmit_interval_max

ndd/dev/tcp

240000

10000

 

tcp_rexmit_interval_min

ndd/dev/tcp

200

3000

 

tcp_smallest_anon_port

ndd/dev/tcp

32768

1024

Set this on clients, too.

tcp_slow_start_initial

ndd/dev/tcp

1

2

Slightly faster transmission of small amounts of data.

tcp_xmit_hiwat

ndd/dev/tcp

8129

32768

Use this to increase the transmit buffer.

tcp_recv_hiwat

ndd/dev/tcp

8129

32768

Use this to increase the receive buffer.

For more information about these parameters, see Chapter 5 of the Sun ONE Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide at:

http://docs.sun.com/source/817-6249/index.html



Previous      Contents      Index      Next     


Part No: 819-3650-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.