At the last regional Java and Open Source conference where I held the presentation named:
“Java Mission Control now in OpenJDK – best practice”, several questions have been raised about a way of testing JEE apps, influence of a GC (Garbage Collector) on the overall performance, new GC engines etc.
With OpenJDK 11 we have a new toy called Z Garbage Collector, while there are plenty of others still available like G1 etc.
Here are the questions that I’m going to answer:
- Is the load/stress test executed by using tool X realistic?
Simple answer is: No.
First you need to understand why are you using some GC, and check if you have a problem that can be solved by changing GC.
Enterprise architecture consists of a many components.
Even if you leave Big Data/ Machine Learning stack on side, you still have a many app servers in cluster, and on each server you have several JEE applications.
You have to add ESB integration (either on the same server or on a separate domain) and keep in mind that each application have a different behaviour.
All in all it will be very difficult and time consuming to create a realistic test.
Load / stress tests are the most useful when you are targeting very specific business process and where the scope of testing is focused only on components that are involved to complete that process.
- What is the GC impact on overall performance in a real system?
Instead of answering on that question, you should better take a look at the next picture taken from the OpenJDK Mission Control session that I’ve presented on the conference.
As you can observe, in 35 minutes (duration of the test), less than 1.5 second has been spent on GC.
Thus even if you replace the GC with a “better one”, in this case the impact will be negligible.
Summary:
The most important knowledge, in case you want to build your career towards performance tuning, is to know how to interpret the results you are getting from some tool.
Today there are many tools available with different strengths and weakness, and it shouldn’t be difficult to get performance data out, but don’t be pushed in the trap describes by an old wisdom: “A fool with a tool is just a fool”.
Thus tool might help you with some graphics and automation of a boring stuff, but to interpret the results and fix the problem you need to have a knowledge of how technology is working under the hood, and that involves knowing of system & software architecture along with all individual components.
Comments