After some investigation, the suspected cause of these high response times was "stop the world" garbage collection and we eventually proved this by monitoring the JVM during a test run. Thankfully, the new Java VMs include a ton of tuning options and I've found the following references particularly useful in the past. * Ergonomics in the 5.0 Java Virtual Machine * J2SE 5.0 Performance White Paper * Java SE HotSpot at a Glance So then, some advice : 1. Make sure that you define your non-functional requirements as early in the project as you can, specifying performance in the context of scalability. Once you've done this, you can focus on figuring out how to meet them. 2. Make sure that you test your key non-functional requirements as soon as possible, preferably with something like a reference architecture. Tuning your JVMs early lets you gauge how much more performance you might get with further tuning in the future. 3. Make sure that you document your JVM settings if you've had to tune them to meet your performance targets. The system I'm testing is a third party product and there's no way that the customer should even be running, what's basically a "real-time" system, on untuned JVMs.Read Simon's complete post: http://www.codingthearchitecture.com/2007/11/05/performance_tuning_java_systems.html
There are numerous tools and API's related to performance tuning, but there can be no substitute for background knowledge on the subject, including hands-on experience resolving bottlenecks, this blog entry explores the issues in a short and concise manner.
This is interesting ... what about performance tuning to take advantage of multi-core processors? I've been working with Software Pipelines. Check this out: http://www.softwarepipelines.org/wiki/Software_Pipelines It's more appropriate for server side business processes with bottlenecks ..... but still interesting.