Java EE 8 High Performance

Romain Manni-Bucau

• Éditeur: Packt Publishing
• Année: 2018
• ISBN:
  9781788472159
• Édition: 1
• Sujet: Ciencia de la computación
• Sous-sujet: Programación en Java

Get more control of your applications performances in development and production and know how to meet your Service Level Agreement on critical microservices.About This Book• Learn how to write a JavaEE application with performance constraints (Service Level Agreement—SLA) leveraging the platform• Learn how to identify bottlenecks and hotspots in your application to fix them• Ensure that you are able to continuously control your performance in production and during developmentWho This Book Is ForIf you're a Java developer looking to improve the performance of your code or simply wanting to take your skills up to the next level, then this book is perfect for you.What You Will Learn• Identify performance bottlenecks in an application• Locate application hotspots using performance tools• Understand the work done under the hood by EE containers and its impact on performance• Identify common patterns to integrate with Java EE applications• Implement transparent caching on your applications• Extract more information from your applications using Java EE without modifying existing code• Ensure constant performance and eliminate regressionIn DetailThe ease with which we write applications has been increasing, but with this comes the need to address their performance. A balancing act between easily implementing complex applications and keeping their performance optimal is a present-day need. In this book, we explore how to achieve this crucial balance while developing and deploying applications with Java EE 8. The book starts by analyzing various Java EE specifications to identify those potentially affecting performance adversely. Then, we move on to monitoring techniques that enable us to identify performance bottlenecks and optimize performance metrics. Next, we look at techniques that help us achieve high performance: memory optimization, concurrency, multi-threading, scaling, and caching. We also look at fault tolerance solutions and the importance of logging. Lastly, you will learn to benchmark your application and also implement solutions for continuous performance evaluation.By the end of the book, you will have gained insights into various techniques and solutions that will help create high-performance applications in the Java EE 8 environment.Style and approachThis book will cover vital concepts implemented through a sample application built throughout the book. This will enable you to apply these concepts to suit your software requirements.

Monitor Your Application

When it comes to an application's performance, you will quickly need to know what your application does and get the metrics of performance. In this chapter, we will identify a few ways to get insights on applications.

Thus, in this chapter, we will learn how to monitor our application's behavior in order to be able to compare it with the response times and execution times we observe. This will therefore show you the following:

• How to add monitoring or profiling to an existing application
• How to read important figures corresponding to the monitoring of an application
• How to ensure that the application performance is monitored and that any unexpected changes are visible

Java tools to know what my application is doing

Two critical factors are directly linked to performance when you take an application as a black box:

• Memory usage: If too much memory is consumed, it can slow down the application or even make it dysfunctional
• CPU time: If an operation is too slow, it will consume a lot of CPU cycles and impact the overall performance

Without too much external tooling (except the Java Development Kit (JDK) and/or operating system tools), you can easily extract a lot of information and start working on the performance.

The jcmd command – the small command line utility that does a lot

Since Java 8, the JDK has been coming with the jcmd command, which allows you to execute commands on a local Java instance using the same user/group as the instance you want to check.

The usage of jcmd, although command-based, is quite simple. To understand it, we will first start our quote manager application with the command we saw in Chapter 1, Money – The Quote Manager Application:

mvn clean package embedded-glassfish:run

Now in another console, just execute jcmd. On my system, it will dump what follows:

$ jcmd
4981 com.intellij.idea.Main
7704 sun.tools.jcmd.JCmd
7577 org.codehaus.plexus.classworlds.launcher.Launcher clean package embedded-glassfish:run
5180 org.jetbrains.idea.maven.server.RemoteMavenServer

The first column is the process ID (PID) of the program and what follows is the launching command (main and parameters). Since we launched our server with maven, we can identify it with the maven main (org.codehaus.plexus.classworlds.launcher.Launcher) or with the parameters that exactly match the command we launched (clean package embedded-glassfish:run).

If you launch a standalone GlassFish, you will probably have a line like the following:

7877 com.sun.enterprise.glassfish.bootstrap.ASMain -upgrade false -domaindir /home/dev/glassfish5/glassfish/domains/domain1 -read-stdin true -asadmin-args --host,,,localhost,,,--port,,,4848,,,--secure=false,,,--terse=false,,,--echo=false,,,--interactive=true,,,start-domain,,,--verbose=false,,,--watchdog=false,,,--debug=false,,,--domaindir,,,/home/dev/glassfish5/glassfish/domains,,,domain1 -domainname domain1 -instancename server -type DAS -verbose false -asadmin-classpath /home/dev/glassfish5/glassfish/lib/client/appserver-cli.jar -debug false -asadmin-classname com.sun.enterprise.admin.cli.AdminMain

This one is pretty verbose but you can identify that the main (first string) references glassfish and you can find the domains directory to distinguish between multiple instances.

To just give you another idea, if you use Apache Tomcat or TomEE, you will identify it with this line:

8112 org.apache.catalina.startup.Bootstrap start

Now, we have the PID of our Java process; we can pass it to jcmd:

jcmd <PID> help

For example, for our previous maven GlassFish instance, it will look like the following:

jcmd 7577 help

The output should look like the following:

7577:
The following commands are available:
JFR.stop
JFR.start
JFR.dump
JFR.check
VM.native_memory
VM.check_commercial_features
VM.unlock_commercial_features
ManagementAgent.stop
ManagementAgent.start_local
ManagementAgent.start
GC.rotate_log
Thread.print
GC.class_stats
GC.class_histogram
GC.heap_dump
GC.run_finalization
GC.run
VM.uptime
VM.flags
VM.system_properties
VM.command_line
VM.version
help

As you can see, the output is basically a list of commands that you can invoke using jcmd. A lot of these commands are informative, such as VM.version (which will just log which JVM you are using), but some commands are actual actions, such as GC.run (which will call System.gc()). Concerning the performance, we are interested in Thread.print, which is a replacement of jstack. GC data commands, such as GC.class_histogram, are related to the garbage collection data, while the JFR commands are related to Java Flight Recorder.

Let's start with the most basic but also probably the most important command: Thread.print. This will allow us to see what our application is doing by digging into the current thread stack of our application.

Thread.print

If you execute the Thread.print command, the output will look like the following:

$ jcmd 7577 Thread.print
7577:
2017-09-10 16:39:12
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):

"....." #xxx [daemon] prio=xxx os_prio=xxx tix=0x.... nid=0x.... [condition]
 java.lang.Thread.State: XXXXX
 at ......
 at ......
 ...


"....." #xxx [daemon] prio=xxx os_prio=xxx tix=0x.... nid=0x.... [condition]
 java.lang.Thread.State: XXXXX
 at ......
 at ......
 ...


"....." #xxx [daemon] prio=xxx os_prio=xxx tix=0x.... nid=0x.... [condition]
 java.lang.Thread.State: XXXXX
 at ......
 at ......
 ...

Since reproducing the full output of this command will take the entire chapter, it has been replaced by a skeleton of sorts of the thread stacks. What is important here is to identify that each block starting with a line that has quotes is a thread.

Therefore, the dump repeats this pattern:

"thread_name" #thread_id_as_int [daemon if the thread is daemon] prio=java_priority os_prio=native_priority tid=thread_id_pointer_format nid=native_id [state]
 thread_stack_trace

When the server is idle—that is, when it is not serving any request or executing any scheduled tasks—we can identify that most of the threads are just waiting for a task (in thread pools):

"dol-jar-scanner" #50 daemon prio=5 os_prio=0 tid=0x00007f3b7dd0a000 nid=0x1ddf waiting on condition [0x00007f3ae6bae000]
 java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for <0x00000000877529a8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
 at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
 at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)

To understand this dump, you will need to know how ExecutorService works. It basically creates threads with tasks called Workers, and each work can take some tasks from a queue (to simplify things). Here we can see the following:

• ThreadPoolExecutor$Work, which means that we are in a thread pool task handler
• LinkedBlockingQueue.take, which means that the thread is waiting for a new task

We can also identify in this dump some incoming requests in the I/O layer, such as waiting for a socket to connect to an NIO Selector:

"http-listener-kernel(1) SelectorRunner" #27 daemon prio=5 os_prio=0 tid=0x00007f3b7cfe7000 nid=0x1dc8 runnable [0x00007f3b1eb7d000]
 java.lang.Thread.State: RUNNABLE
 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
 at sun.nio.c...