In this teaser blog post, we’ll take you through some of the answers we have received so far in our Java Performance survey, which incidentally is still running so please take the survey before we do our full analysis of the data. Use the button below to take you directly to the survey (Oh and by the way, we’re still donating 50c for every completed survey to Dogs for the Disabled, so you can feel great while filling it in).
Of the 1442 survey responses we have received so far, 65% of them are software developers and a further 27% comprised System Architects, Team Leads and Project Managers. The main application worked on by 70% of respondents work on is a web app, with 11% working on a desktop app and a further 10% working on a Batch or Mobile application.
The first question we’ll look at is all about whose responsibility it is to profile the application and performance test it (note that multiple options could be selected). Over half of respondents state that the responsibility sits with whoever writes the code. The senior developer and architect was also a strong option for many, reaching 39% and 23% respectively. 193 people admitted to nobody on the team being responsible for it, almost the same number as those who have a dedicated performance team.
The most common issue that plagues our respondents is slow request times, rather than outages or failed requests. In fact 2 in 3 respondents state this is the most common issue. This of course is the just symptom and there are many different problems that might be the cause, as we’ll see next.
Did I mention the survey was really friendly? I’m not sure if you actually realise how friendly that is, so I wanted to be certain you’re aware, it’s really friendly
The typical root causes that most respondents experience are database related issues, with 56% noticing slow DB queries and 39% stating their requests invoke too many database queries. Perhaps there’s some poor Hibernate or JPA usage in there? Did someone say n+1? ;) Inefficient application code was also a concern with over half of our survey takers stating this as a common root cause.
As you’d expect with the main symptom being slow request times and the main root causes being inefficient application code, too many and slow database queries, the areas people measure are similar. Application responsiveness is the most popular point, with Memory usage interestingly coming next. Database query performance and Application code/CPU performance were also strong on the list of responses. 9% of respondents don’t measure at all… shame on you!
OK, so this survey now wants to be your best friend. Don’t let your new best friend down, make them proud.
Thanks for reading all the way through this post and I hope you enjoyed the data so far. We’ve got a lot of work ahead to pivoting over the data points to better understand where the trends are and whether people working on bigger apps prefer certain tools, or whether those who have more complex apps suffer from different types of problems and much more. For this to be a success however, we really need your support. You can help by providing us with more data to analyse. By the way, a massive thank you if you’ve already taken the survey, and please go take it if you haven’t :) Let me know if there’s anything you want me to look at whilst analysing the data and if you have any suggested pivot points on the data you’d like me to work on.