BreadcrumbHomeResourcesBlog 2020 Java Performance Report January 27, 2020 2020 Java Performance ReportDeveloper ProductivityJava Application DevelopmentOur 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. *The 2024 Java Developer Productivity Report is here. Get the latest stats. Table of ContentsJava Performance Survey ResultsImpact of Java Reloads and RedeploysFinal ThoughtsTable of Contents1 - Java Performance Survey Results2 - Impact of Java Reloads and Redeploys3 - Final ThoughtsBack to topJava Performance Survey ResultsWith 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 issuesPerformance verificationPerformance issues reaching productionImpact of redeploysYou 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 ReportNon-Functional Requirements for Java PerformanceThe days of sending potentially non-performant code to deployment are over — at least for half of our respondents. 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 JRebelCommon Java Performance IssuesOne 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 timeMemory leaksHigh CPU usageToo many open connectionsExcessive IO queriesOtherIn cases where the respondent marked Other, they were asked to specify the issue.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 JRebelVerifying Java Application Performance RequirementsThere 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 itPerformance tests in CIManual ad hoc QAAPM finds it in productionCustomers report itResponses for this question went well over one per person, showing us that performance requirements are commonly addressed throughout the application lifecycle.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 ProductionDespite 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.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.Back to topImpact of Java Reloads and RedeploysIt 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 TimesRedeploys 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.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!Back to topFinal ThoughtsAnd, 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 ResourcesLooking 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.2020 Java Productivity Report2020 Trends in Java Development Webinar2020 Java Productivity Report Overview2020 Java Microservices Report2020 Java Technology ReportWant to see the full report? Click the button below to access it now.DOWNLOAD FULL 2020 REPORTBack to top