This is the first article in the series of articles exploring the tools and techniques for analyzing, monitoring, and improving the performance of Java applications.
The Art of Java Application Performance Analysis and Tuning-Part 2 The Art of Java Application Performance Analysis and Tuning-Part 3 The Art of Java Application Performance Analysis and Tuning-Part 4 The Art of Java Application Performance Analysis and Tuning-Part 5 The Art of Java Application Performance Analysis and Tuning-Part 6 The Art of Java Application Performance Analysis and Tuning-Part 7
In this blog we are going to discuss basic terminology and performance methodology.
Excerpts from the book “Java Concurrency In Practice” by Brian Goetz..
Application performance can be measured in a number of ways, such as response time, latency, throughput, scalability, or capacity. Some of these (response time, latency) are measures of “how fast” a given unit of work can be processed or acknowledged; others (capacity, throughput, scalability) are measures of “how much” work can be performed with a given quantity of computing resources.
Throughput is the amount of work that a application can do in a given time period.
Example: Number of Jobs completed in a hour.
Scalability describes the ability to improve throughput or capacity when additional computing resources (such as additional CPUs, memory, storage, or I/O bandwidth) are added.”
Example: Say a Java application can complete 100 Jobs in 10 hours on a given hardware/DB configuration. Can the application complete 200 Jobs in 10 hours by doubling/increasing hardware/DB configuration?
If the application completes the above task without modifying the code then we say the application is scalable.
The “how much” aspects scalability, throughput, and capacity are usually of greater concern for server applications than the “how fast” aspects. For interactive/web applications, response time, latency tends to be more important, so that users need not wait for longer periods
to see the results.
Improving Application Performance?
Improving performance means doing more work with fewer resources.
Here “resources” means CPU cycles, Memory, network bandwidth, I/O bandwidth, database requests, disk space etc.. In practice the performance of an activity/application is limited by one or more of these resources. When the performance of an activity is limited by availability of a particular resource, we say it is bound by that resource: CPU-bound, Database-bound, I/O-bound etc.
What about your application? Is it CPU-bound? or Database-bound? or Memory-bound?
Tuning for throughput/capacity, the goal is usually to do the same work with less effort, such as by using better algorithms or using caching techniques.
Tuning for scalability, the goal is to find ways to parallelize the problem so you can take advantage of additional processing resources to do more work with more resources.
When Application Tuning is Required?
Safety always comes first. Here “safety” means the functionality of the application/program. First make your program right, then make it fast. And then tune further only if your performance requirements tell you it needs to be faster.
When Application Tuning is Required?
- If your application/feature is not performing as expected.
- On QA/Customer complaints
- If your Project requires
If an application is performing as well as expected, you don’t need to put additional efforts to enhance its performance.
Performance Analysis and Tuning Methodology
Performance analysis and tuning is a iterative process.
Any performance tuning activity involves taking decisions and trade-offs. And these decisions/trade-off involve multiple variables (Application, O/S, DB, Cache) and are specific to project requirements. So before deciding that one approach/decision is “faster”/”better”
than another, we need the understand the effect these decisions..
So for each of the performance decisions we need to understand
Under what conditions will this approach actually be faster?
Example: Hardware/DB configuration, Application Settings, Cache Settings etc..
Under light or heavy load?
Example: No. of parallel threads, thread count, No. of Concurrent Clients, No. Of Processing Threads etc..
With large or small (input/processing) data?
Example: small database, large database
All performance decisions should be supported with measurements.
Fig A. shows a flow chart from the book Java Performance co-authored by Charlie Hunt and Binu John. This chart shows the process of Java application performance tuning.
Performance tuning exercise should be accompanied by
- Concrete performance requirements. So that you know the target performance and know when to end the tuning activity.
- Test Program/Time Stamps/Logs to measure the program
- Required load/data/input to test the program
Step 1: The process starts with setting concrete performance requirements.
Step 2: After we have the baseline data, we are ready to begin our performance tests by increasing the load (or) increasing the data size/network size (or) increasing the input size.
Step 3: We need to measure/analyze the application using tools like thread dump , JConsole and profiler etc.
Step 4: From the performance analysis/results collected, we can identify the bottlenecks that may have caused issues such as slow response times and high resource usage.
Step 5: Make the required application/configuration changes.
Step 6: Measure again after tuning/making changes to verify that you’ve achieved the desired improvements.
Step 7: Repeat above steps until you meet your performance requirements.
Application performance analysis/tuning requires systems knowledge.
For example, you need knowledge on
- Java virtual machines (Oracle Java, IBM Java)
- Operating Systems (Linux/Solaris/IBM AIX)
- Computer and Database architectures (MySQL/Oracle)
- Third Party Tools/libraries (Hibernate, Profilers etc.)
When you apply the systems knowledge on your application deployment, you can successfully tune an application.