2020 Java Performance Report
January 27, 2020

2020 Java Performance Report

Developer Productivity
Java Application Development

Our 2020 Java Performance Report is based on the results of our 2020 Java Developer Productivity Survey. In this survey we asked Java development professionals on their technology preferences, team composition, application performance, redeploy times, and issues surrounding microservices development. 

Java Performance Survey Results

With the emergence of DevOps, developers are taking on more responsibility for application performance during development. In fact, our survey found that the majority of developers are now responsible for non-functional performance requirements.

In our Java performance survey segment, we look at the details surrounding application performance, including;

  • Common performance issues
  • Performance verification
  • Performance issues reaching production
  • Impact of redeploys

You can view survey results for these questions below. Or, if you want to see the full report, you can click the button below to view the pdf version of the report.

Download 2020 Report

Non-Functional Requirements for Java Performance

The days of sending potentially non-performant code to deployment are over — at least for half of our respondents. 

2020 Java Performance Report - Non-Functional Performance Requirements Chart

51% of respondents reported that they have non-functional requirements defined for performance in their development project, with 49% reporting the opposite.

Is this due to the necessities of microservices development? Or the shifting development responsibilities with DevOps? Or is this just an emerging focus for developers? Regardless, more developers have non-functional requirements for application performance than those who do not.

It was interesting to see just how many developers now have non-functional performance requirements. It may be a testament to how experienced our respondents are, but it definitely reinforces a trend of developers being asked to play a more hands on role in performance testing — regardless of experience level.

— Curtis Johnson, Product Manager at JRebel

Common Java Performance Issues

One of our favorite questions to ask developers is about where they’re experiencing performance issues. Understanding this gives us a grasp of what development teams experience when it comes to performance issues.

For the purpose of this survey, we broke these common performance issues into six categories:

  • Long application response time
  • Memory leaks
  • High CPU usage
  • Too many open connections
  • Excessive IO queries
  • Other

In cases where the respondent marked Other, they were asked to specify the issue.

2020 Java Performance Report - Common Java Performance Issues Chart

55% of respondents reported the most common performance issue was long application response time. While this isn’t a surprise, it does mark a continuing trend for developers. The trend also aligns with microservices adoption, which is notable for developers considering a transition to the architecture.

The next highest was memory leaks at 28% of respondents. High CPU usage marked the third most common issue at 28% of respondents, with excessive open connections and IO queries coming in at 24% and 15% respectively.

10% of respondents chose other, but there were no statistically notable answers from those who wrote in.

Long application response time can be a complex issue, further complicated by third party requests. It's not surprising to see this one reported as the biggest performance issue.

— Curtis Johnson, Product Manager at JRebel

Looking for a way to troubleshoot your application performance during development? Be sure to check out our real-time performance troubleshooting tool, XRebel. It works well in architecturally-complex applications, making tracing performance impact across services easy for developers of all levels.

See an XRebel Demo

Verifying Java Application Performance Requirements

There are many ways in which Java development teams verify application performance requirements. But, for the purpose of this survey, we limited it to five different responses:

  • Developers test it
  • Performance tests in CI
  • Manual ad hoc QA
  • APM finds it in production
  • Customers report it

Responses for this question went well over one per person, showing us that performance requirements are commonly addressed throughout the application lifecycle.

2020 Java Performance Report - Verifying Java Application Performance Chart

70% of respondents reported that developers tested for performance, while 43% reported testing for performance during continuous integration.

37% reported that they verify performance via manual ad hoc quality assurance, and 32% reported that they use customer reports to inform their performance success.

Lastly, 10% of respondents reported that they verify performance with application performance management technology.

Java Performance Issues Reaching Production

Despite the increasing responsibilities for developers to test performance during development, performance issues still reach production. Our survey found that over 78% of teams had issues that reached production in the last 12 months.

2020 Java Performance Report - Java Performance Issues Reaching Production Chart

While it wasn’t happening regularly for most respondents, (only 17% reported experiencing issues regularly) 62% of developers reported performance issues experienced during production.

The lucky minority who didn’t experience issues during production comprised 21% of overall respondents.

Impact of Java Reloads and Redeploys

It wouldn’t be a JRebel survey without asking about how the build process affects developers. After all, our flagship product, JRebel, is built on helping developers to skip rebuilds and redeploys.

But learning how the build process affects developers can give us valuable insights into the reasons why people use and don’t use JRebel.

Of the 231 who answered the question, we found a common theme — slow build processes negatively impact the developer and the code.

Average Redeploy Times

Redeploys take too long, regardless of how long they take. But for some developers, redeploys can go from annoyance to development roadblock.

In this survey question, we asked developers to place their redeployment time onto a scale of zero minutes to ten minutes plus.

2020 Java Performance Report - Average Redeploy Times for Java Developers Chart

For 32% of respondents, the most common redeploy time was between two to three minutes. The next most common redeploy time, at 20% of respondents, was up to one minute per redeploy.

The surprising thing for us was that, despite the widespread adoption of microservices, over 48% of developers experienced reload times of over four minutes. 

Perhaps even more surprising was that over 15% of our respondents reported reload times of over ten minutes!

Final Thoughts

And, just like Java technology usage rates, these performance issues grow and shift as new ideas work their way into the Java ecosystem.

Take microservices as the glaring example, and one we’ll talk about at length in the next chapter: they rely on independently functioning services that can communicate and interact with other services within an application.

But, because of the rapid advances in how these individual containers can interact, and the seemingly infinite combinations of ways that they can cause performance issues as the application grows more complex, microservices have proven to be a veritable Pandora’s box of new performance issues.

Additional Resources

Looking for additional insights into Java development in 2020? Our full report and segments break down the results of our last Java developer survey, and provide commentary from our Java experts.

Want to see the full report? Click the button below to access it now.

DOWNLOAD FULL 2020 REPORT