Glassfish tuning list that I want to keep for the time being

This article is the 10th day article of "Java EE Advent Calendar 2016". Day 9 (previous day): @megascus "[Modularize and combine Java EE Web applications](http://d.hatena.ne.jp/megascus/ 20161209/1481252793) " Day 11 (Tomorrow): @yyYank

Introduction

It's been a year and a half since I started Java EE. During development, I had the opportunity to investigate Glassfish performance tuning, so I will summarize what I investigated at that time.

Glassfish (and other application servers) is "development-optimized" by default. Regarding the automatic deployment function, dynamic reloading, and JVM, priority is given to the faster ** "start" ** over the faster ** "run" **. While these features are very useful during the development phase, they can be a performance bottleneck during the production phase.

It's important to know how to tune Glassfish, both to provide better service and to know how to optimize your settings for your production environment.

This time, I will explain the basic performance tuning of Glassfish.

** Note: Tuning during development is not recommended and makes no sense. The tempo of development slows down. ** **

The parameters that depend on the environment are defined as follows.

Also, when adding settings to the configuration file,

add to

<!--Additional settings-->

If you want to change the settings

Change before

<!--Settings before change-->

After change

<!--Settings after change-->

It is represented by.

Tuning type

There are three main types of tuning.

1. JVM tuning
2. Glassfish tuning
3. Program tuning

** 1. JVM tuning ** is the idea of "let's speed up the people who run Glassfish in the first place". It can be applied to other Java programs. ** 2. Glassfish Tuning ** literally optimizes the settings of Glassfish itself for speed. ** 3. Program Tuning ** is to optimize the program itself that Glassfish will run. We will try to speed up by making full use of more memory-efficient code and techniques. Not covered in this article.

JVM tuning

First, let's think about tuning the JVM. After setting, restart the target domain. The JVM settings when starting Glassfish are described in the <glassfish> / domains / <domain-name> /config/domain.xml file. In the file

domain.xml

<java-config ...>
 <jvm-options>..</jvm-options>
 <jvm-options>..</jvm-options>
 <jvm-options>..</jvm-options>
</java-config>

I think there is a part. This is the option to pass to the JVM when Glassfish starts.

1. To work in server mode

Change before

<jvm-options>-client</jvm-options>

After change

<jvm-options>-server</jvm-options>

Please refer to the following for the difference between server mode and client mode. Reference --Real differences between “java -server” and “java -client”?

2. Output garbage collection log

add to

<jvm-options>-verbose:gc</jvm-options> <!--Enable GC logging-->
<jvm-options>-XX:+PrintGCDetails</jvm-options> <!--More detailed output-->
<jvm-options>-Xloggc:/path/to/logfile.log</jvm-options> <!--Output to file-->

Please set the log output destination to \ . If you have memory problems or want to find out if you have enough allocated memory, check the logs for suspicious behavior in garbage collection. Reference-Garbage Collection: A brief explanation and research method for GC (Garbage Collection)

If you want to know more detailed information about GC, please refer to the following. Supplement --A summary of Java's GC options.

3. Disable System # gc ()

add to

<jvm-options>-XX：+DisableExplicitGC</jvm-options>

Please refer to the following URL for the disadvantages of manually executing System # gc (). Reference --Distribution of WebSphere: Part 5 "Running System # gc ()"

4. Change the memory allocated to the heap area

Change before

<jvm-options>-Xmx512m</jvm-options>

By default, it is set to allocate 512MB. How much memory is allocated is optimized by load test and garbage collection log, but if you are not particular about it, let's set the value to "Allocated up to this point for the time being". If there is no problem, set it to "2GB".

After change

<jvm-options>-Xms2048m</jvm-options>
<jvm-options>-Xmx2048m</jvm-options>

"-Xms" represents the initial value and "-Xmx" represents the maximum value, but it is best practice to match them. If the initial value and the maximum value do not match, unnecessary allocation processing will occur. If there is no particular problem, let's match. Below is a more detailed memory tuning reference URL. If you are interested, please read it and add the settings as appropriate. Reference-JVM tuning

You may have expanded the heap area due to frequent GCs, but the problem persists. Note that this may be a problem with the program of the running application. See below for details Supplement --- 9. Increasing the heap size solves the memory problem

The tuning of the JVM is hard to dig into, so I'll finish it here. If you are interested, please check it out.

Glassfish tuning

We will tune Honmaru and Glassfish. You can change the settings from the management console (localhost: 4848), but it is recommended that you use a command that allows you to organize the processes as a script. If you save it as a script, you will not have to change the settings every time you set up the server.

Hereafter, we will use the command ʻasadmin, which is located in / bin / asadmin`.

1. Disable automatic deployment

$ ./asadmin set server.admin-service.das-config.autodeploy-enabled=false`

It's a convenient auto-deploy feature, but it's not needed during the production stage, so turn it off.

2. Disable dynamic reloading

$ ./asadmin set server.admin-service.das-config.dynamic-reload-enabled=false

Dynamic reloading is a function that automatically reflects changes in the application without restarting the server. It's very convenient, but when it's enabled, Glassfish keeps checking for changes at regular intervals. Turn it off to improve performance. By default, it checks every 2 seconds. If you don't want to turn it off, but want some performance gains, set this interval longer.

When changing the interval to 1 minute

$ ./asadmin set server.admin-service.das-config.dynamic-reload-poll-interval-in-seconds=60

3. Precompile JSP

$ ./asadmin set server.admin-service.das-config.autodeploy-jsp-precompilation-enabled=true

Improve performance by precompiling JSP (Java Server Pages).

4. Tighten the log level

$ ./asadmin set-log-levels <logger-name>=WARNING

Exporting a large number of logs will result in poor performance. Basically, at the production stage, it is enough to have logs of WARNING level or higher, so if there is no problem, let's set the log level of the logger to WARNING. (You can list loggers and their log levels with the ./asadmin list-log-levels command)

** Caution: It is safe to spit out a lot of logs while the system is not stable, such as at the beginning of operation **

5. Enable genStrAsCharArray

The genStrAsCharArray option is an option that treats a string as an array of characters. Treating it as an array of chars saves memory and reduces overhead. This tuning is ridiculed as "micro-optimization", but if dust accumulates ...

Add to the setting part related to jsp Servlet in <glassfish> /domains/<domain-name>/default-web.xml.

add to

<servlet>
    <servlet-name>jsp</servlet-name>
    ...
    ...
    <!--Additional part-->
    <init-param>
       <param-name>genStrAsCharArray</param-name>
       <param-value>true</param-value>
    </init-param>
    <!-- /Additional part-->
</servlet>

in conclusion

It's been a year since the last Java EE Advent Calendar 2015 that I participated in for the first time. I am worried about the future, such as Oracle smelling the end of Java EE development, but I would like Java EE to do its best without losing the headwind.