Chapter 4 Common Performance Problems
This chapter discusses common web site performance problems, and includes the following topics:
Note –
For platform-specific issues, seeChapter 6, Platform-specific Issues and Tips
Magnus Editor Values
You can set most of the tuning parameter values of the magnus.conf file using the Magnus Editor in the Server Manager. However, note that once you have set the values, the Administration Server does not verify that they are valid.
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 aclid properties from virtual server tags in server.xml. 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 Sun Java System Web Server must 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 server will spawn by lowering the value of the MaxProcs value.
Your web applications running under stress may sometimes result in the server running out of Java VM runtime heap space, as can be seen by java.lang.OutOfMemoryError messages in the server log file. There could be several reasons for this (such as excessive allocation of objects), but such behavior could affect performance. To address this problem, you would need to profile the application. Refer to the following HotSpot VM performance FAQ for tips on profiling allocations (objects and their sizes) of your application:
http://java.sun.com/docs/hotspot/PerformanceFAQ.html
At times your application could be running out of maximum sessions (as evidenced by the "too many active sessions message" in the server log file), which would result in the container throwing exceptions, which in turn impacts application performance. A due consideration of session manager properties, session creation activity (note that JSPs have session enabled by default), and session idle time would be needed to address this situation.
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 Sun Java System Web 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, seeMaximum Simultaneous RequestsMaximum 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. Do not 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 Server Manager. 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. For more information, seeCache Information
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 also 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 Server Manager. For more information, seeKeep-Alive/Persistent Connection 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 could.
To reduce keep-alive flushes, increase the MaxKeepAliveConnections value in the magnus.conf file or the Magnus Editor of the Server Manager. The default value is 256. By raising the value, you keep more waiting keep-alive connections open.
Caution – On UNIX/Linux systems, if the MaxKeepAliveConnections 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.
Log File Modes
Keeping the log files on verbose mode can have a significant impact on performance. You can set LogVerbose to "on" in magnus.conf or the Magnus Editor of the Server Manager.
- © 2010, Oracle Corporation and/or its affiliates