Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

The Developer’s Guide to Java Performance Tuning

Good developers care about performance. However, even the best developers don’t realize that performance tools are not a one-size-fits-all type deal, rather they’re components in a suit of armor. You see, a suit of armor has many pieces – a breastplate, a helmet, gauntlets, etc. – all of which are designed specifically for different parts of the body. We’ll be defining 4 major types of performance tools and which areas of the (figurative) body they’re designed for, and finally, honing in on the solution best suited for development.

But First, Understand Your Options

Let’s quickly look at existing types of Java performance tools out there:

Profilers give you a Swiss Army Knife solution to help you research complex or already known issues. They often require you to generate a synthetic workload in order to sample your application and provide you with a report to help identify hot spots in your application.
Performance Monitoring Tools monitor the JVM and aggregate detailed info for troubleshooting complex JVM issues such as garbage collection inefficiencies, memory leaks or locked threads.
Application Performance Management Tools are platforms that give you a bird’s eye view of the performance of your applications and production infrastructure using real-time, real end-user workloads to help organizations resolve production fires faster.
XRebel is ??? Curious? Read on!

What’s wrong with what we do now?

Delivering a working solution to end-users on time is always in the forefront of the long list of product requirements, shortly followed by multiple aspects of software:

Functionality, to deliver valueable features to users
Quality, to prevent critical bugs
Performance, to achieve great end-user experience

A classic mantra is “make it work, make it work well, make it work fast”; The listed aspects are typically weighted in the above order, with performance only receiving attention after achieving the required functionality and quality.

And this comes as no surprise. In organizations that have a throw-it-over-the-wall separation of teams, it’s not the developer’s job to care about performance, rather, it’s to deliver functionally accurate code. Conversely, we ran a survey which asked who in their organization is responsible for fixing performance issues and 94% of our respondents reported that it falls on development – the same shoulders as whoever wrote the code in the first place! Well damn.

*Responses do not sum up to 100% because the original question was in multi-select form

Beyond job responsibilities, we all know (or if you don’t know, you’re in denial) that development is the most effective phase in the SDLC for performance tuning because that’s when issues are easiest to debug and cheapest to fix; it’s always more time-consuming to redo and maintain bad code than it is to do it the right way from the get-go. So the challenge with performance that we wanted to address is how to create a way to tune for performance as early on as possible without interrupting the developer workflow.

But before designing a plan of attack, we must learn about the enemy.

Deconstructing Performance Issues

When you’re performance tuning, innately the lowest hanging fruit is to fix those bugs that cause performance degradation rather than trying to improve healthy code. And that’s why in the same survey mentioned above, we asked respondents to list the types of performance issues they see in their applications. The following results revealed that the 5 most common performance issues that crop up are:

*Responses do not sum up to 100% because the original question was in multi-select form

The first three issues are by far the most prevalent, being responsible for the majority of end-user impact. More interestingly, these are application layer issues that don’t require load to manifest.

Doesn’t this blow your freakin’ mind?! It blows ours. Because this means that it is entirely possible to create a performance solution that:

Saves time: It reduces rework by delivering a way to performance tune during initial development
Is easy to use: It seamlessly integrates into the development workflow
Is proactive: It helps developers understand and eliminate smelly code before any testing occurs
Is effective: It targets only the most common performance issues

And that’s how XRebel was conceived, boys and girls.

Performance First

We’ve already established that development is the most efficient time to care about performance because developers are actually responsible for performance, despite what they’ve been told, and it makes everyone happier because you can stop fixing other people’s bugs and go back to doing more meaningful, fulfilling, sexy feature work!

The best part about XRebel is that it makes performance first development easy by putting it into your process without you actually having to change anything about your existing process – something that can be considered unfeasible, if not impossible.

“Isn’t it counter-productive to be cognizant of performance in development?” Well, performance doesn’t have to be as elusive as you want to make it.

1. Performance tuning requires the developer to have an intimate understanding of the requirements and expected performance thresholds of the feature, but performance benchmarks can’t be established that early on.

2. Even if these benchmarks are extrapolated somehow, performance results will be completely different on a development machine than on a staging or production environment where the product will ultimately reside.

And here’s how you should address these areas:

1. Rather than paying attention to the exact timings of every method, pay closer attention to the percentage of the response time a method takes up in a transaction.

2. Pay attention to the deltas of the percentages as you add more features, and focus on keeping it minimal.

Beyond that, performance has a few other interesting angles. For example, you want to measure the fully assembled application, and then find the hotspots in a given transaction. You can’t measure units as that brings you down the rabbit hole of micro-optimization, and as we mentioned before, we don’t want to waste time optimizing otherwise healthy code. If you go too far the other way, we start running into the traditional ways of doing performance with synthetic workloads and test cases. But that’s too bulky for development and in turn, not iterative.

What you need is the perfect middle ground. This is exactly how XRebel carves its own path in the sea of performance tools.

XRebel is a javaagent and only requires an application server and an HTML5 compliant browser. It works with monolithic and microservices applications. Upon server startup, it automatically injects an HTML widget into the bottom left corner of your application window. That widget temporarily houses request execution breakdowns, IO, and web service call data using the normal traffic generated as you functionally test a local instance of your application. So without having to generate load, logs or use any cumbersome tools, you now have a continuous feed of real-time performance data presented in a single pane of glass under your nose.


XRebel makes it easy to see if the web page you’re on generates an inordinate number of database queries because of a simple misusage of an ORM, or if you’re over-optimizing your data by storing too much in your session objects. Even if you’re not a performance-obsessed developer (how have you gotten this far?) you can spare yourself some embarrassment by fixing issues before anyone else sees them.

As a bonus, if you’re using our other tool, JRebel, you can reload any code changes on the fly without bouncing your server, which means you can see the performance impact of any changes to your codebase instantly! Sweet baby James Gosling!

So the lesson for today is that you need to identify the gaps within your software delivery cycle and suit up accordingly. Make sure you’re doing performance early, often, and during initial development. Focusing on performance doesn’t have to be a drag if every developer on the team has a hand in it, which you can pull off with XRebel.

Learn about The Performance Pipeline!

What to read next…

SQLCheatSheetThumb3 5reasonsforXRThumb