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
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.
|<glassfish>||Path where Glassfish is installed|
|<domain-name>||Domain name to be tuned|
Also, when adding settings to the configuration file,
If you want to change the settings
<!--Settings before change-->
<!--Settings after change-->
It is represented by.
There are three main types of 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.
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
<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.
Please refer to the following for the difference between server mode and client mode. Reference --Real differences between “java -server” and “java -client”?
<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 want to know more detailed information about GC, please refer to the following. Supplement --A summary of Java's GC options.
Please refer to the following URL for the disadvantages of manually executing System # gc (). Reference --Distribution of WebSphere: Part 5 "Running System # gc ()"
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".
"-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.
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
$ ./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.
$ ./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
$ ./asadmin set server.admin-service.das-config.autodeploy-jsp-precompilation-enabled=true
Improve performance by precompiling JSP (Java Server Pages).
$ ./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 **
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
<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>
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.