I recently came across some projects, that in fact needed some performance tunings. Doing so, I was also looking for some best practices and white papers around.
Found this one: Optimize GlassFish Performance in a Production Environment, Performance White Paper, February 2009 (Sun)
It is designed for users requiring general guidance for initial tuning values in order to improve the application performance on the Sun GlassFish application server v2.
This paper provides the Introductory Steps to achieving better performance for the Sun GlassFish application server v2 application with descriptions of the Eleven tuning parameters; General Recommendations, which can be used to optimize the performance of the application server; and Data from a benchmarking exercise that demonstrates the effectiveness of the tuning changes.
Contents
Tip 1: Java Version
Obious .. change to latest JVM if possible.
Tip 2: JVM Mode
GF runs with -client ootb. change to -server
Tip 3: Java Heap Size
Give your server, hat it needs.
By default, the GlassFish application server is set to 512 MB
and the limit for a 32 bit JVM version- is approximately 3.5GB on Solaris, and 1.5
GB on Windows without any operating system tweaks.
Further information is available in this JVM Tunin White Paper!
Tip 4: Tune Java Garbage Collection
A deeper understanding is necessary when tinkering with GC tuning options and it is strongly recommended to read Tuning Garbage Collection with the Java Virtual
Machine for more details and GC strategies.
Tip 5: HTTP acceptor threads
HTTP acceptor threads accept new incoming connections and schedule new
requests for the existing connections. The default number of acceptor threads is one! It is recommended to have 1 thread per 1-4 core.
Tip 6: HTTP request processing threads
This pool of threads retrieve and process incoming HTTP requests. The default
number of request processing threads is 5 but a starting rule of thumb is to tune
the number of HTTP request processing threads to the number of CPUs.
Tip 7: Optimize Keep Alive subsystem
This subsystem prevents the server from being overloaded with connections. A
waiting keep alive connection has completed processing the previous request,
and is waiting for a new request to arrive on the same connection.
Three factors describe the Keep-Alive behavior. Keep-Alive timeout, Keep-Alive max connections and thread-count. Performance tuning in this subsystem highly depends on your applications needs.
Tip 8: Optimize static content delivery
If your application contains static files, it is recommended to enable HTTP file
cache to optimize performance. This should not be relevant for clusters running httpd with mod_proxy or similar in front.
Tip 9: Use default-web.xml to disable dev features
The default-web.xml file defines features such as filters and security constraints
that apply to all web applications. You should use it, to define some common constraints that are performance critic to all deployed applications. Most common two are this:
<init-param>
<param-name>development</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>genStrAsCharArray</param-name>
<param-value>true</param-value>
</init-param>
Tip 10: JDBC Tuning
Tune the steady-pool-size and the max-pool-size, and set them to the same
value. This will avoid unnecessary resizing of the pool. A general
rule of thumb is to tune the value for max-pool-size and steady-pool-size to the
same number of HTTP request processing threads.
Tip 11: Disable Access Logging
To avoid unnecessary I/O activity, disable the access
logging.
Further readings:
Sun Java System Application Server 9.1 Performance Tuning Guide
