Software QA FYI - SQAFYI

How to Stress Testing Java EE 6 Applications with JMeter and VisualVM

By: Mohamed Taman

How to Stress Testing Java EE 6 Applications with JMeter and VisualVM

JEE6: Stress Testing Java EE 6 Applications, how to? Use stress testing to identify application server configuration problems, potential bottlenecks, synchronization bugs, and memory leaks in Java EE 6 code.

Unit and integration tests are helpful for the identification of business logic bugs, but in the context of Java Platform, Enterprise Edition 6 (Java EE 6), they are meaningless. Both integration and unit tests access your application in a single-threaded way.

After the deployment, however, your code will always be executed concurrently.

Stop Talking, Start Stressing
It is impossible to predict all nontrivial bottlenecks, deadlocks, and potential memory leaks by having theoretical discussions. It is also impossible to find memory leaks with unit and integration tests. Bottlenecks are caused by locks and I/O problems that are hard to identify in a single-threaded scenario. With lots of luck and patience, memory leaks can be identified with an integration test, but they can be far more easily spotted under massive load.

The heavier the load, the greater is the probability of spotting potential concurrency and robustness problems. Cache behavior, the frequency of Java Persistence API (JPA) OptimisticLockException, and the amount of memory needed in production can also be evaluated easily with stress tests.

Even in the unlikely case of a perfect application without defects, your application server will typically be unable to handle the load with default factory settings. Stress tests are a perfect tool to learn the behavior of your application under load in the first iterations without any stress. Stress test-driven development is the right choice for Java EE.

Instead of applying optimizations prematurely, you should concentrate on implementing pure business logic and verifying the expected behavior with automated tests and hard numbers.

Java EE 6 applications are always executed concurrently. Even with unrealistic stress tests, you will learn a lot about system behavior and identify some bottlenecks or concurrency bugs.

Don’t Be Realistic
Load tests are configured by taking into account the expected number of concurrent users and realistic user behavior. To meet the requirements, “think times” need to be kept realistic, which in turn reduces the amount of concurrency in the system. The heavier the load, the easier it is to find problems.

Realistic load tests are usually performed too late in the development cycle and are useful only for ensuring that nonfunctional requirements are met. They are less valuable in verifying system correctness.

Instead of relying on realistic but lax load tests defined by domain experts, we should realize as much load as possible using developer driven stress tests. The goal is not to verify expected scalability or performance. Instead, it is to find bugs and learn about the behavior of the system under load.

Stressing the Oracle
My “oracle” application records predictions and returns them as a JavaScript Object Notation (JSON) string. (For more information on the “oracle” application, see “Unit Testing for Java EE.”) Sending a GET request to the URI http://localhost:8080/oracle/resources/predictions returns a Prediction entity serialized as {"prediction":{"result":"JAVA_IS_DEAD","predictionDate":"1970-01-01T19:57:39+01:00","success":"false"}}. Services provided by Java API for RESTful Web Services (JAXRS) are easily stress-testable; you need only execute several HTTP requests concurrently.

The open source load testing tool Apache JMeter comes with built-in HTTP support. After creating the ThreadGroup and setting the number of threads (and, thus, concurrent users), an HTTP request has to be configured to execute the GET requests (right-click, select Sampler, and then select HTTP

Full article...

Other Resource

... to read more articles, visit

How to Stress Testing Java EE 6 Applications with JMeter and VisualVM