Adam Bien's Weblog

The next item from the Java EE Fallacies. Developers often ignore the fact, that most of the Java EE applications are distributed, concurrent applications, and are relatively happy with a green bar. To make things more exciting some developers love to mock everything which could cause problems (database, backend systems etc.) AND forget (often even do not want) to test the application again in real world production-near environment. Event with continuus integration like cruise control, contnuum etc. you only test your code in production-similar environment in a sequential way.
Because the advantage of Java EE is the ability to process concurrent users, it would be also interesting to test the application under load. In this case it is not so important to check the performance, it is more important to ensure the long term stability. The tests do not have to be realistic, the main motivation for such tests is to see the application's behavior under heavy load (night run). CPU, memory consumption, the pool size and request distribution among the cluster nodes should be stable. It is amazing how many, deadlocks, non-working XA-transactions, consistency issues, OutOfMemory, memory leaks, bottlenecks (synchronized methods) etc. you will see. Some of these issues can even need a complete refactoring of your business and UI-logic (e.g. moving from pessimistic to optimistic locks). To minimize the costs, a distributed application should be load-tested at least once a week. My observation: Java EE application are load tested only few weeks before production. Because there is no more time to fix the problems - no one really cares about the results...

Some useful tools:

1. JMeter, Grinder, OpenSta(if possible LoadRunner). Load testing frameworks
   
2. JunitPerf:  collection of JUnit test decorators used to measure the performance and scalability of functionality contained within existing JUnit tests.
3. JConsole: part of Java SE 5. A JMX-monitoring tool. You can monitor easily the CPU, RAM, Threads etc.
   
4. LoadRunner (commercial one), is expensive but also powerful.
   

Posted at 01:01PM Oct 23, 2006 by Adam Bien in Enterprise Architekturen, Leitfaden für Effiziente Softwareentwicklung  |  Kommentare[1]

[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices