GlassFish Performance Tunning

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


• Maximum heap size of 1/4th of the physical memory, up to 1GB.


–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.




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)

The more  configuration optimization can be done using the document from SUN you can download it here

Download – OptimizeGlassFishPerformance.pdf

About Anoop Nair

I am a Linux and Networking geek, Interest to learn more and fun to do new experiments, happy to share knowledge that I have learned and experienced in my life and carrier, also trying to learn more on Firewalls, Linux, Switching, Routing etc..............

Check Also

Nslookup correct reply

NSlookup incorrectly appending domain name in windows 10

Noticed this problem in Windows 7 and windows 10 systems after adding the system to …