Appendix A Common Performance Problems

If Application Server must run in low-memory situations, reduce the thread limit to a bare minimum by lowering the value of the HTTP service Thread Count setting.


Note	The Troubleshooting Guide useful in resolving common problems with the Application Server.

Under-Throttled Server

The server does not allow the number of active threads to exceed the thread limit value. If the number of simultaneous requests reaches that limit, the server stops servicing new connections until the old connections are freed up. This can lead to increased response time.

In Application Server, the server's default RqThrottle value is 128. If you want your server to process more requests concurrently, increase the RqThrottle value.

The symptom of an under-throttled server is a server with a long response time. Making a request from a browser establishes a connection fairly quickly to the server, but on under-throttled servers it can take a long time before the response comes back to the client.

The best way to tell if your server is being throttled is to see if the number of active sessions is close to, or equal to, the maximum number allowed via RqThrottle. To do this, see Thread Count.

Cache Not Utilized

If the cache is not utilized, your server is not performing optimally. Since most sites have lots of GIF or JPEG files that can always be cacheable, use cache effectively.

Some sites, however, do almost everything through CGIs, SHTML, or other dynamic sources. Dynamic content is generally not cacheable, and inherently yields a low cache hit rate. Don't be too alarmed if your site has a low cache hit rate. The most important thing is that the response time is low. It is possible to have a very low cache hit rate and still have very good response time. As long as the response time is good, a low cache hit might not matter.

Check your Hit Ratio using statistics from perfdump or the Monitor Current Activity page of the web-based Admin Console. The hit ratio is the percentage of times the cache was used with all hits to your server. A good cache hit rate is anything above 50%. Some sites may even achieve 98% or higher.

In addition, if you are doing a lot of CGI or NSAPI calls, you may have a low cache hit rate. If you have custom NSAPI functions, you might have a low cache hit rate.

Keep-Alive Connections Flushed

A web site that might be able to service 75 requests per second without keep-alive connections, may 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 being used effectively. If the KeepAliveCount exceeds the MaxKeepAliveConnections, subsequent keep-alive connections will be closed, or `flushed', instead of being honored and kept alive.

Check the KeepAliveFlushes and KeepAliveHits values using statistics from perfdump or the Monitor Current Activity page of the web-based Admin Console. 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 could.

To reduce keep-alive flushes, increase the MaxKeepAliveConnections value in the init.conf file or the web-based Admin Console. The default value is 200. By raising the value, you keep more waiting keep-alive connections open.



Caution	On Unix systems, if you increase the MaxKeepAliveConnections value too high, the server can run out of open file descriptors. Typically 1024 is the limit for open files on Unix, so increasing this value above 500 is not recommended.

Log File Modes

Keeping the log files on verbose mode can have a significant affect of performance. Set LogVerbose to any level higher than FINE using the web-based Admin Console.

Additional Resources

SE Toolkit
http://www.setoolkit.com
Gets system performance data in a color-coded GUI.

GC Portal: http://java.sun.com/developer/technicalArticles/Programming/GCPortal/
How to configure the vm parameters.

Solaris Tunable Parameters reference manual.
http://docs.sun.com/db/doc/806-7009

JDK performance
http://java.sun.com/performance

Linux performance and other information:

http://www.tldp.org

http://linuxperf.nl.linux.org/

Solaris information:

http://www.sun.com/bigadmin/patches
For performance patches.

http://www.sun.com/bigadmin/
For a variety of other resources.

Previous Contents Index Next
Sun Java System Application Server Enterprise Edition 8 2004Q4 Beta Performance Tuning Guide