Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Performance and Tuning Guide

> ## Appendix A
> Common Performance Problems

> This section discusses a few common web site performance problems to check for:

> - check-acl Server Application Functions
> - Low-Memory Situations
> - Under-Throttled Server
> - Cache Not Utilized
> - Keep-Alive Connections Flushed
> - Log File Modes
> - Additional Resources

>   Note | You will find the Troubleshooting Guide useful in resolving common problems with the Application Server.

> ##

> check-acl Server Application Functions

> For optimal performance of your server, use ACLs only when required.

> The default 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 your server's performance by removing the aclis properties from virtual server tags in <instance_name>-obj.conf. This stops any ACL processing.

> You can also improve performance by removing the check-acl SAF from the default object for URIs that are not protected by ACLs.

> ##

> Low-Memory Situations

> If you need Application Server to run in low-memory situations, reduce the thread limit to a bare minimum by lowering the value of RqThrottle. Also, you may want to reduce the maximum number of processes that the Application Server will spawn by lowering the value of the MaxProcs value.

> ##

> 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, you need to 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 may 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 Maximum Simultaneous Requests.

> ##

> 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 should always be cacheable, you need to use your 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 your response time is low. You can have a very low cache hit rate and still have very good response time. As long as your response time is good, you may not care that the cache hit rate is low.

> 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 may 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. You can set LogVerbose to any level higher than FINE using the web-based Admin Console.

> ##

> Additional Resources

> Places to go for additional information:

> - Monitoring Current Activity Using the perfdump Utility
> - 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

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.