Category Archives: Performance

No time for monitoring?

Monitoring big, distributed Java landscapes helps tremendously to keep complex applications under control. But many administrators spare the effort to set up monitoring: No time. Now a timesaving solution is in sight.

„We are maxed out anyway. We need a solution that helps to make our work more effective and not something that if we are lucky saves about as much time as it needs to set it up and maintain it“.
I hear statements like those again and again from IT administrators. With the effect that APM solutions are mainly used for firefighting by experts.

So, what is needed? A solution which allows to monitor a large number of applications with a minimum of configuration effort and identifies the root cause of problems quickly.

Indeed I found and tested a tool which fulfills those requirements. (read more…)

Rainer Schuppe

 

Easy Performance Analysis with AppDynamics Lite

AppDynamics is the rising star in the Application Performance Management sky.

Mirko gives a really good description why AppDynamics delivers the right solutions for todays distributed architectures in his Post “Troubleshoot Java in production – introducing AppDynamics Lite“. If you have not read it yet, head over to it now.

The key promise of AppDynamics is simplicity. Easy installation, easy operation and very fast results. In fact this sounds uncommon and hard to believe. But this is indeed the case, as proven by the following uncut screencasts.
(read more…)

Fabian Lange

 

Troubleshoot Java in production – introducing AppDynamics Lite

The performance and stability of Java applications in production is getting more and more critical. Most (if not all) of todays businesses rely on software. More and more of these applications use web or mobile technologies to directly offer service to customers or integrate with partners. These applications often leverage other applications or services to deliver the expected result. The infrastructure on which these services and application run is virtualized and will move to public or private clouds in the near future.

(read more…)

Mirko Novakovic

 

Believing in Numbers

What follows is in my view a typical scenario of one of the common curses of the performance tester. A new version of a test object finds its way into my hands. After some twiddling with it to get it running, I do a first quick test run. Somebody – development, architecture, project management, whoever – gets wind of it and is curious about the results. Defensively, I try a delaying tactic: “It’s the very first run. The test environment wasn’t completely built up. We have to do more tests. We must at first confirm the numbers before it makes any sense to discuss them.” My counterpart is getting more inquisitive. He insists to be aware of all of my objections and that he just wants to satisfy his curiosity. I finally give in and tell the numbers. Shortly thereafter, I regret it deeply. Like an avalanche, my little piece of information has gathered a gigantic mass in no time and like a boomerang it is coming full circle, heading straight back at me.
(read more…)

Dr. Raymond Georg Snatzke

 

Richfaces Sessions Eating Memory – Analysis of a Memory Leak

When developing a site in JSF many people like to use the Richfaces Framework. It is a pretty solid framework that comes wit a lot of functionality and nice components. It also comes with an Ajax framework called Ajax4JSF (also called a4j). When deploying this site then facing the Internet to production, many people start finding out that their applications eat a lot of memory, leading to unresponsive systems or OutOfMemoryError crashes. This is due to a design issue in JSF / A4J and cannot be easily fixed, but worked around. But lets start with an analysis of whats wrong with our otherwise nice application.
(read more…)

Fabian Lange

 

Invoking System.gc() can have serious impact

Not taking JavaDoc seriously can easily happen to any developer. Or maybe you haven’t read that specific part of it, you should better have read. If you did and cannot see a problem locally, you might be tempted to ignore it.

Here is an often ignored part from java.text.SimpleDateFormat JavaDoc:

 * Date formats are not synchronized.
 * It is recommended to create separate format instances for each thread.
 * If multiple threads access a format concurrently, it must be synchronized
 * externally.

Perhaps that warning isn’t strong enough, because it reads: “It is recommended”.
This leads to this highly dangerous line of code I have seen in almost every project and is likely to produce hangs in concurrently accessed code.

private static final SimpleDataFormat DATE_FORMAT = new SimpleDateFormat("yyyy.MM.dd");

But it gets worse with System.gc(). (read more…)

Fabian Lange

 

© 2010 codecentric