Troubleshooting Java Performance - by Erik Ostermueller (Paperback)

About the Book

Tagline: A repeatable method for addressing performance problems in Java-based applications

Book Synopsis

Provides a brief Java performance curriculum with 12 run-on-your-own-machine performance puzzles, all aimed at making you dramatically more productive in getting to root cause

Gives expert load generation advice, including how to determine the precise load necessary to test a given application's scalability

Shows how to detect memory leaks in minutes without a heap dump, and without restarting the suspect JVM

From the Back Cover

Troubleshoot the most widespread and pernicious Java performance problems using a set of open-source and freely-available tools that will make you dramatically more productive in finding the root causes of slow performance. This is a brief book that focuses on a small number of performance anti-patterns, and you'll find that most problems you encounter fit into one of these anti-patterns. The book provides a specific method in a series of steps referred to as the "P.A.t.h. Checklist" that encompasses persistence, alien systems, threads, and heap management. These steps guide you through a troubleshooting process that is repeatable, that you can apply to any performance problem in a Java application. This technique is especially helpful in 'dark' environments with little monitoring.
Performance problems are not always localized to Java, but often fall into the realms of database access and server load. This book gives attention to both of these issues through examples showing how to identify repetitive SQL, and identify architecture-wide performance problems ahead of production rollout. Learn how to apply load like an expert, and determine how much load to apply to determine whether your system scales. Included are walk-throughs of a dozen server-side performance puzzles that are ready to run on your own machine. Following these examples helps you learn to:

• Assess the performance health of four main problems areas in a Java system: The P.A.t.h. Checklist presents each area with its own set of plug-it-in-now tools
  
• Pinpoint the code at fault for CPU and other bottlenecks without a Java profiler
• Find memory leaks in just minutes using heapSpank, the author's open-source leak detector utility that is freely available from heapSpank.org

The repeatable method provided in this book is an antidote to lackluster average response times that are multi-second throughout the industry. This book provides a long absent, easy-to-follow, performance training regimen that will benefit anyone programming in Java.
What You Will Learn:

• Avoid the 6 most common ways to mess up a load test
  
• Determine the exact number of threads to dial into the load generator to test your system's scalability
  
• Detect the three most common SQL performance anti-patterns
  
• Measure network response times of calls to back-end systems ('alien systems')
  
• Identify whether garbage collection performance is healthy or unhealthy and whether delays are caused by problems in the old or new generation, so you know which generation needs to be adjusted
  

About the Author

Erik Ostermueller is a Java architect who is passionate about performance engineering. He has spent the last 10 years leading international performance engineering teams, tuning high-throughput Java financial systems in North and South America, Europe and Asia. In 2011, he presented a paper entitled "How to Help Developers (Finally) Find Their Own Performance Defects" at the Computer Measurement Group's annual conference, where he won "Best Paper" and the "Mullen Award" for best speaker. The proceeds of this award financed an eight-city speaking tour in the US, Canada, the UK, and Italy.

Erik is the technical lead for the Performance Center of Excellence at FIS Global. He is the founder of heapSpank.org, wuqiSpank.org, and a contributor to JMeter-Plugins.org and other open source projects. He lives in Little Rock, Arkansas and plays soccer, tennis, and the piano.