Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

News July 2013

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC 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

Get rid of your performance problems and memory leaks!

Back to newsletter 152 contents

Simple reasoning tells you that the combination of the following three things makes for an inherently unstable system that can cause serious systemic damage:

  1. Having bugs;
  2. No automated systemwide ability to monitor, shutdown and move into a failsafe mode;
  3. Being fast;
This is because:
  1. Bugs means the system is potentially unstable. But most systems have bugs and many are fairly stable, because most bugs are resource stabilising: they cause failures in subsystems that prevent the subsystems from proceeding rather than causing damage. The kind of bugs that cause systemic damage need to enable "runaway" damage - there are always some of these, they're just rarer;
  2. Systemwide failsafety would guarantee that the system is much more stable in the face of hitting a bug but these safe-modes are only ever built into life-critical software (e.g. nuclear/aircraft/rocket control and life support systems).
  3. A slow system hitting a bug that causes "runaway" systemic damage has much more time to be shutdown before the damage becomes serious. The faster the system, the more likely the damage will be serious before it can be halted.

A note from this newsletter's sponsor

Get total visibility in just 15 minutes with AppDynamics Lite,
A performance monitoring tool for Java/.NET apps.
It installs in minutes and it's free forever. Download AppDynamics Lite today.

All this sounds a little esoteric, so how about I give you a real example that lost nearly half a billion dollars? Many of you will already have heard of Knight Capital's disastrous trading crash in 2012. This was caused by precisely the combination above: (1) a bug causing every trade to lose a little bit of money managed to get out to the production system; (2) there was either no automated systemwide monitoring for excessive loss, or else no automated capability to turn off trading; (3) the system was sufficiently fast that by the time it could be stopped, nearly half a billion dollars had already been lost. Note that the bug on it's own was not what caused the damage, it was the combination of repeatedly hitting it in a short time frame and lack of timely shutdown.

You might say that's an extreme example. But the only difference here is that the runaway system caused such an obviously large monetary loss. The faster your system, the more damage it can cause in a runaway situation. If the quest for ever lower-latency is not matched with a parallel quest for automated monitoring, control and failsafety features, then we're just storing up catastrophic failure for the future. The faster a system can go, the faster it can utilise a bug, and the faster bad things can happen before someone notices and stops it. You should always consider what will stop your system in time if it hits a runaway bug.

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

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.


Java performance tuning related news.


Java performance tuning related tools.

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin


Jack Shirazi

Back to newsletter 152 contents

Last Updated: 2023-08-28
Copyright © 2000-2023 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us