JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 153 contents

Load on the server is NOT a measure of user performance. For example, if a user's session gets killed or frozen, that reduces the load on the server. But for sure performance has not improved for that user. To take this to extreme, if all the user sessions freeze or die (or any combination of those two), load on the server looks magnificently low, but performance has gone to pot. Yet I continue to find operations groups who use load on the server as a proxy for what they think must be user experience. "Are you sure there's a problem? we can't see any load on the server." is the typical response. "Please try again".

A note from this newsletter's sponsor

Trying again is even a reasonable suggestion, many problems are from a glitch in a session somewhere which caused the session to freeze or die. The 'IT Crowd' running joke "have you turned it off and on again" is a reasonable suggestion to many glitches. In a browser most people will refresh the page when it hasn't appeared after about four seconds; or click a button again if they see no response from clicking it the first time. But if "try again" works, that doesn't mean you've solved the issue, it means you've just worked around it. Most operations are happy to leave it there, and most users are equally happy, after all it's working now and that's mainly what matters. But there's a glitch somewhere, and glitches tend to come back when you least want them, especially under load when it can make things even worse on your system (hanging connections from abandoned sessions that have been restarted has caused more than one server to run out of resources).

All of this means you need to measure user performance from the user side. That way you can see when user performance is bad; and you can detect any widespread glitches that users are working around with restarts, which can come back to bite you when you don't have the capacity to handle lots of user restarts. And that user performance measurement and reporting needs to be built in to your application, not simulated or inferred. If you aren't measuring user performance from the user perspective, you are missing the most important metric in your system.

Now on to all our usual links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• Bing does hundreds of experiments on users every day, including degrading service, to find what is most important - for example deliberately slowing responses showed that every 100ms improvement in response time improved revenue by 0.6%
• Takipi JVM monitor, now includes Garbage Collection Analysis
• The relationship between heap used and native memory used is complex: heap used+perm used+(threads*thread stack size)+some more for other things like garbage collector extra space, JIT compilation space + code caches, dirrect buffers, JNI space, and some other spaces. Use top (Linux), Activity Monitor (OSX), Task Manager (Windows) to get the OS memory usage; and vmmap (OSX), pmap (Linux), sysinternals VMMap (Windows) to break down how the OS memory is allocated
• Nice explanation of the G1 garbage collector at work. Also a useful note to keep in mind that CMS will always eventually get a concurrent mode failure (so a long full GC of approx 1 second per GB) unless you don't fill tenured space

Tools

Java performance tuning related tools.

• Perclipse - Eclipse plugin for Perfidix benchmarker
• efficiently store large collections of data in memory
• Metrics java monitoring library
• Jvmtop is a lightweight console application to monitor all accessible running jvms on a machine. Includes thread views and a sampling profiler

A note from this newsletter's sponsor

Articles

• Understanding the Java HotSpot VM Code Cache (Ben Evans/Oracle)
• Using Java in Low Latency Environments (Charles Humble, Peter Lawrey, Martin Thompson, Todd L. Montgomery, Andy Piper/)
• Garbage Collection - Let the VM do it (Jon Masamitsu/Oracle)
• C++ like Java for low latency (Peter Lawrey/vanillajava)
• Tuning the Size of Your Thread Pool (Kirk Pepperdine/infoQ)
• Java Garbage Collection Distilled (Martin Thompson/mechanical-sympathy)

Jack Shirazi

Back to newsletter 153 contents