Binbert Technology | Computer | Security | Networking | Mobile
GlassFish is an application/web server for deploying Java based web application. To obtain best performance in production environment, some modification has to be made to the default GlassFish installation.
Tip 1: Java Version
Typically, many performance optimizations are always being incorporated in newer releases of Java SE. Whenever possible, it is a good idea to upgrade to the latest version of Java SE Platform-to take advantage of these optimizations
To change Java version, edit the $GLASSFISH_HOME/config/asenv.conf.
Change the property called “AS_JAVA” to point to the desired Java version.
Tip 2: Java Settings
By default, the GlassFish application server is configured to use the client VM (GlassFish application server is installed in developer profile). For better performance, it is recommended to change this to “-server”.
Java Heap Size and other settings
-Xms and -Xmx
The size of the heap is determined by the Java options -Xmx (maximum) and -Xms (minimum). While a larger heap can contain more objects and reduce the frequency of garbage collection, it may result in longer garbage collection times especially for a full GC cycle. The optimum value for Xms and Xmx can be determined by the following points
initial and maximum heap sizes are
• Initial heap size of 1/64th of the physical memory, up to 1GB. (Note that the minimum initial heap size
is 32MB, since a server-class machine is defined to have at least 2GB of memory and 1/64th of 2GB is
32MB.)
• Maximum heap size of 1/4th of the physical memory, up to 1GB.
-XX:NewRatio
–XX:NewRatio=n 8 on server JVM
Ratio between the young and old generations. For example, if n is 3, then the ratio is 1:3 and the combined size of Eden and the survivor spaces is
one fourth of the total size of the young and old generations.
-XX:MaxPermSize
-XX:MaxPermSize=256m
-XX:+UseParallelGC
By default, the serial collector is the default garbage collector and is typically used for single processor machines and a small heap. However, on server-class machines with more than one processor, parallel GC is the default. Ensure that parallel GC is being used (-XX:+UseParallelGC) for multithreaded machines which uses multiple threads for minor collections. Major collections are the same as serial collector.
This options can be set via Administration console:
1. Use the web browser URL: http:<yourhostname>:4848 (the default
admin port)
2. Login with administrator user and password
3. Click on Application Server node on the left hand side, JVM settings
tab on the right hand side, then JVM options.
4. Edit the desired JVM option (or add New) in the textbox.
5. Click Save on the right hand side
Tip 3 – 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, although experimentation may be necessary to find the optimal number.
This options can be set via Administration console:
1. Login at the administration URL: http://<yourhostname>:4848
2. Expand the node on the left hand side by clicking on Configuration –>
HTTP Service –> HTTP Listeners
3. Click on http-listener-1.
4. Edit the “Acceptor Threads” field under the Advanced setting.
Tip 4 – 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 on the
SUT. If you application is I/O bound, you can start with double the number of
CPUs. Increase this number of threads until your throughput starts to decline. At
the point when your throughput starts to suffer, the request processing threads
are starting to contend for CPU resources so some experimentation will be
necessary to find the sweet spot.
via Administration console:
1. Login at the administration URL: http://<yourhostname>:4848
2. Expand the node on the left hand side by clicking on Configuration –>
HTTP Service
3. Click on RequestProcessing Tab on right hand side.
4. Edit the text box beside Thread Count.
5. Click Save and restart.
Tip 5 – Default-web.xml
The default-web.xml file defines features such as filters and security constraints that apply to all web applications. The parameter, development=true, (the default value for developer profile) enables changes made to JSPTM – code to be instantly visible to the clients. However, there is a cost associated with this. To avoid the cost of checking whether the JSP code has been modified and hence its recompilation, the first parameter, development=false, can be used to set development to false since this scenario is unlikely in a production system. This check affects application scalability when multiple users request the same JSP class. The second parameter, genStrAsCharArray=true, changes the way the JSPs are generated by generating char arrays for every static strings in the JSP class like for example, the HTML tags. By default, the JSPcode writer must call the toCharArray() on every String on every invocation of the JSPclass.
Settings in default-web.xml. ($GLASSFISH_HOME/domains/domain1/config/default-web.xml)
<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>
The more configuration optimization can be done using the document from SUN you can download it here
Nice post Anoop. Liked every bit of it..