11.5 Tuning Procedure

I l @ ve RuBoard

The overall tuning procedure for enterprise projects follows the strategies for J2SE projects. The main difference is contention. Eliminating contention in J2SE applications is mostly a matter of identifying and eliminating deadlocks, or balancing the occasional shared resource. Contention in enterprise systems tends to occur throughout the system, arises quite easily, varies as the application scales , and can be difficult to identify. Contention for multiuser resources is usually the factor that limits the theoretical performance of an enterprise system, which means that if you can tune away the implementation bottlenecks, you will probably be left with the contention bottlenecks.

Again, here are some best practices from the J2SE world that are applicable here:

  • Measure the performance using logging, monitors , profilers, and benchmark suites, and by instrumenting code.

  • Don't tune any benchmarks that have already reached the target performance.

  • Identify the main bottlenecks (look for the top five bottlenecks, but go higher or lower if you prefer).

  • Determine whether bottlenecks are related to CPU, memory, or I/O problems, and try to accurately identify their cause.

  • Choose the quickest and easiest bottleneck to fix and address it. Target only one bottleneck at a time.

  • Think of a hypothesis for the cause of the bottleneck.

  • Consider any factors that might refute your hypothesis.

  • Create a test to isolate the factor identified by the hypothesis.

  • Test the hypothesis.

  • Alter the application to reduce the bottleneck.

  • Test that the alteration improves performance and measure the improvement (regression-test the affected code).

  • Make sure that the tuning exercise has improved speed. The most common tuning mistake is to assume that a change has improved performance without testing it, only to find at some point later that the change actually decreased performance.

  • Document optimizations fully in the code. Retain old code in comments. Tuned code can sometimes be difficult to understand.

  • Quality-test the application after any optimizations have been made. An optimization is not fully valid until it has passed QA.

  • Repeat the whole tuning procedure for the next bottleneck.

I l @ ve RuBoard

The OReilly Java Authors - JavaT Enterprise Best Practices
The OReilly Java Authors - JavaT Enterprise Best Practices
Year: 2002
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net