For platform-specific issues, see Chapter 4, Platform-Specific Issues and Tips
For optimal server performance, use ACLs only when required.
The server is configured with an ACL file containing the default ACL allowing write access to the server only to all, and an es-internal ACL for restricting write access for anybody. The latter protects the manuals, icons, and search UI files in the server.
The default obj.conf file has NameTrans lines mapping the directories that need to be read-only to the es-internal object, which in turn has a check-acl SAF for the es-internal ACL.
The default object also contains a check-acl SAF for the default ACL.
You can improve performance by removing the check-acl SAF from the default object for URIs that are not protected by ACLs.
Certain performance issues can be tracked down to a specific aspect of the server configuration. For example, it is common practice to use the assign-name NameTrans directive in obj.conf to apply rules based on request URL pattern. More and more assign-name directives get added as time goes by and specific requirements come up, and it is not unusual to see configurations with the number of assign-name directives running into hundreds.
Each assign-name directive introduces a regular expression comparison, which can be CPU intensive. Hence, as the number of such directives increase, performace start getting affected.
For more information on this specific topic, see Chapter 6, Scalability Studies.
The server automatically selects many server defaults based on the system resources, for optimal performance. However, if the server's chosen defaults are not suited to your configuration, you can override them. .
The File Cache configuration, especially when non-default, can impact memory usage. Similarly, the ACL Cache size should be controlled using the ACL Cache Tuning in Sun Java System Web Proxy Server 4.0.11 Release Notes, if needed.
The server does not allow the number of active threads to exceed the thread limit value. If the number of simultaneous requests reaches that limit, the server stops servicing new connections until the old connections are freed up. This can lead to increased response time.
In Proxy Server, the server’s default maximum threads setting is greater of 128 or the number of processors in the system. If you want your server to process more requests concurrently, you need to increase the maximum number of threads.
The symptom of a server with too few threads is a long response time. Making a request from a browser establishes a connection fairly quickly to the server, but if there are too few threads on the server it can take a long time before the response comes back to the client.
The best way to tell if your server is being throttled by too few threads is to see if the number of active sessions is close to, or equal to, the maximum number of threads. To do this, see Thread Information.
Check your hit ratio using statistics from perfdump, the Admin console Monitoring tab. The hit ratio is the percentage of times the cache was used with all hits to your server. For more information, see File Cache Statistics Information.
A Proxy site that can service 75 requests per second without keep-alive connections might be able to do 200-300 requests per second when keep-alive is enabled. Therefore, as a client requests various items from a single page, it is important that keep-alive connections are used effectively. If the KeepAliveCount shown in perfdump (Total Number of Connections Added, as displayed in the Admin Console) exceeds the keep-alive maximum connections, subsequent keep-alive connections are closed, or “flushed,” instead of being honored and kept alive.
Check the KeepAliveFlushes and KeepAliveHits values using statistics from perfdump or the Number of Connections Flushed and Number of Connections Processed under Keep Alive Statistics on the Monitoring Statistics page. For more information, see Keep-Alive Information.
On a site where keep-alive connections are running well, the ratio of KeepAliveFlushes to KeepAliveHits is very low. If the ratio is high (greater than 1:1), your site is probably not utilizing keep-alive connections as well as it can.
To reduce keep-alive flushes, increase the keep-alive maximum connections. You can do this using the "MaxKeepAliveConnections" magnus.conf parameter. The default is based on the number of available file descriptors in the system. By raising the keep-alive maximum connections value, you keep more waiting keep-alive connections open.
On UNIX/Linux systems, if the keep-alive maximum connections value is too high, the server can run out of open file descriptors. Typically 1024 is the limit for open files on UNIX/Linux, so increasing this value above 500 is not recommended.
Garbage collection can affect performance in some cases, especially with very high cache sizes. Garbage Collection is a CPU and Disk intensive activity that, by default, involves iterating through the entire cache structure and deleting enough files to bring down the cache size as per the limits imposed by the caching configuration.
Garbage Collection is Automatic by default, which means that the Proxy server has a dedicated "Garbage Collection Thread" which periodically wakes up to inspect the cache and perform Garbage Collection if needed.
Using the admin GUI, Garbage Collection can be changed to Scheduled which disables the in-process Garbage Collection thread. This can help improve performance, as Scheduled Garbage Collection is achieved using the cachegc command line utility and can be configured to run only at specific times on specific days.