Performance is 99% about understanding the problems
That is why you need to perfectly understand your application, its needs and abilities, and feel comfortable using a range of performance related tools: APMs, profilers, testing libraries that will help you solve the issues you have.
When trying to pin down the top factors impacting application performance, the right answer is that there is no right answer… the source of a performance problem could be almost anywhere!
– Julie Craig, Research Director, Application Management, Enterprise Management Associates (EMA)
An Introduction to Performance
Java Performance tools are all very different and have typically been created for different reasons and to achieve different goals. Which Java Performance tools are you going to use in your next project and why would you choose one over the other? There are many aspects which may sway your decision and of course it will depend on the type of application you’re building. This report will cover Java Performance Considerations, Java Monitoring Tools, Java Profilers, and Performance Testing Tools. We will also demonstrate a few of our favorite Java Performance tools on a reference application to help you get the answers you seek.
If you are not actively looking for answers to your performance issues yet, consider this simple fact: performance affects your bottom line. The performance of your system often directly translates into its utility for the end user. Keeping your end users happy can have a major effect on your bottom line. For instance, you may lose business if your e-commerce site cannot handle the Black Friday loads, or if your business is high performance trading, a delay of a couple of milliseconds could be the difference between covering your body in gold leaf or simply just leaves.
Google exposed the fundamental importance of performance to end users when they revealed that people engage with web-pages more when they load faster. More engagement means more conversions and returning customers. And despite the fact that you can always compete with others on better service, prices or whatever else you have to offer, not tapping into the additional benefits that a faster system can offer is just not very smart.
Obviously, if you’re a developer at a legacy software shop, you might not bother yourself with such matters. You are proud of the work that you do and the quality of the code you produce. Your end users are effectively the operations team who have a very particular set of skills that sometimes make them a nightmare for developers such as yourself. Your code’s performance can make the difference between them creating a developer shrine for you, the ideal developer, or just printing out your profile picture to be used as dartboard fodder.
WHAT IS PERFORMANCE?
It might seem like an unusual question in a report about performance as most people tend to already have a good idea about what the term ‘performance’ means. However, it’s common that different people will have a different perspective in the way they might describe it. For instance, some may say being performant is doing the same task with fewer resources. This might be by design, by choosing a more lightweight stack rather than just increasing system hardware. Others may approach the topic differently, by trying to eliminate bottlenecks, i.e. the part of the system which is performing least well. Others might say increasing performance is to eliminate unnecessary actions. The truth is, well, all of these are performance related actions. Ultimately being performant is about increasing user response times and reducing latency in all parts of your system and as a whole, while being functionally accurate and consistent to your end user. Now the question is… how?
In this report, we will not take sides or focus on the scalability of the system or try to make it run as fast as a caffeinated cheetah on a single-core machine. Instead, we’ll look at the different tools and techniques that allow you to understand the balance between the resources your system has and how it utilizes them: where does your system perform most of the work and where should you look first if you need to tweak the balance.
In the next chapter we’ll look at a list of resources you have to take into account when talking about performance and define the functional requirements of their utilization.
This is a great place to mention low-level code performance and benchmarking. For instance, is
x=x+1? How much slower is an
ArrayListat appending millions of items compared to a
LinkedList? This is a very code-centric approach and while it has a place in the software engineering eco-system and is a very fascinating area of developer growth, we will not focus on the benchmarking tools or ways to solve low-level code performance questions in this report. Sorry fans of tail-call-optimizations and on-stack-replacements, we’ll cover it another time. Today we’re focusing on the high-level overview of system performance and establishing the right balance between the resources and requirements.
– Oleg Šelajev, Head of RebelLabs, Content Warlock at ZeroTurnaround