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 ... 

Javva The Hutt April 2009

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 101 contents | All Javva's articles

The 1st
Have improved the throughput on the claims processing system five-fold, using all the usual tuning techniques, caching, elminating contention points, pooling, a bit of code speedup. All is in the next release, I have put all the tasks into the release build, so in QA now.

The 15th
QA cycle complete, now going to release in 2 days, it's a big jump in capability, not just increased throughput, but existing throughput is faster too. Have only noted there are 'some' performance improvements in the release, am awaiting post-release measurements before I send out a nice 'look what I did' circular.

The 18th
Release went out yesterday. The proverbial hit the fan. I'm not entirely sure yet, all I know is that it was disastrous, we all have to check our release items, there's a total change freeze on everything until the issues have been resolved. The freeze order came from top management, so stuff is serious!

The 23rd
Things are clearer now. The release caused a serious issue. Phantom claims of some kind were generated. Actual money was lost. Enough money that it went to the board level. Mind you, nowadays that probably isn't that much money anyway, but rumours here are of millions. Anyway, turned out to be in a piece of code that sneaked in, only gets exercised in the deployed system and never in QA due to lack of coverage. Board level meetings on our QA coverage, people buzzing around looking very downcast, someone got a serious telling off. It's mostly explained, except for one puzzling aspect. The post-mortem analysis explained everything except for one detail - the money flew out the door a lot faster than they would have expected it to flow, given the usual processing rate of the system. It's apparently very puzzling. People are jokingly calling it the credit crunch system because it seems able to process losing money four times faster than it can when the money was flowing in.

The 24th
The system was reverted to the prior release, and now all items in the future releases are on an absolutely only-definitely-needed-and-reviewed-multiple-times-and-QAed-thoroughly procedure, so all of my changes have been left for much later. I shall feed them in, bit by bit. There will be no big bang speedup, it will be a slow trickle of improvements over time. Probably best all round, I think. Making a system faster at losing money is probably not something I want on my CV.

BCNU - Javva The Hutt.

Back to newsletter 101 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