There is a lot of talk about Java Developers testing their own code. Everyone assumes it makes for better code, but does it? Well, if you haven’t yet checked out the latest report from RebelLabs which surveyed over 1500 Java Developers “Developer Productivity Report 2015: Java Performance Survey Results”, you definitely should.
The report found that the teams that have the happiest users (less users affected by performance) followed the following best practices:
- Work in smaller teams – 30% smaller teams that design, develop, test and support the application.
- Have less complex applications – 38% fewer application screens/views.
- Test earlier – 36% more likely to run performance testing while they code.
- Are more efficient – 38% faster at diagnosing, fixing, and testing performance issues.
- Look after their databases – 20-25% less likely to have database query or slow DB issues.
- Are more proactive – Almost 40% more likely to profile on a daily or weekly basis.
- Are less reactive – Almost 20% less likely to test reactively when issues arise.
As a profiler vendor ourselves it only seems natural to see how XRebel fits in with the findings of the report. Let’s look at each of the categories and see if XRebel rocks or sucks in each of them. *Note* This is where the XRebel product team cross their fingers and hope their market research and hunches have paid off.
Work in Smaller Teams & Have Less Complex Applications
This is somewhat more of an observation than a recommendation, but we can learn something from it. You would expect more complex applications to have more complex use cases and scenarios which lead to more issues both performance based and not. Similarly, you’d expect those with larger applications will tend have larger teams to cater for all the workload. These aren’t necessarily things you can just fix. You can’t just wake up and say, you know what, I’m going to reduce the complexity of my application! Some problems are complex and need complex solutions. Others are fortunately simple. There are ways that can help though, including componentizing your application which breaks it down and perhaps has multiple teams working on multiple components, but this really goes beyond the scope of the survey results and as mentioned is something that is interesting to look at. As this isn’t a tooling based observation, the use of XRebel in this instance will not change any metrics.
Testing earlier in the cycle is an approach much advocated among many for unit and functional testing. However, performance testing rarely gets thought about in the same light because… we’ll there isn’t really a because clause here as it should be considered part of developer testing! Yes, there are some tests that do require production load and and the environment to be more realistic to get accurate numbers and results, but there are a huge number of tests that don’t require this restriction and can be run earlier. For instance, if your session is getting too big, it’ll happen in production just as easily as development. If you’re calling 100 SQL queries in production, there’s a very good chance you’ll be doing similar in development.
So why do people not test earlier? Well, testing is hard! Even the installation and setup can be a major accomplishment when you get it working if you’re not a performance expert. With XRebel, installation is as simple as adding a single Java property on your JRE. Setup is already done for you and every time you click on your application, XRebel is working in the background, testing away and notifying you about problems. Issues are found while the code is being developed, before it’s even been pushed to a team repository! How’s that for early? Any earlier and the code would still be in the developers brain! — We’re looking into this in version 3.0 ;o)
Be More Efficient
Being able to test effectively and quickly is something that’s more likely going to make developers test. Also, it’s been shown both in the report and other studies that when issues are found earlier in the development cycle, they take much less time to complete.
XRebel certainly helps in this aspect as it’s UI and UX have been carefully designed so that developers get just enough information to know where to fix performance bugs, without having to be performance experts. This allows developers to pin point problems and without drilling down through gig after gig of lots or output. Plus by being a development time tool, by design, it will aid finding bugs earlier, making them cheaper to fix.
Look After Your Databases
Databases are one of the key areas which performance bugs are found. Most notably in there being too many SQL queries and slow SQL queries. However it’s very easy to write code whereby the developer will have no idea how many SQL queries will actually be executed. Why? Because ORM! Hibernate is a great example of an ORM which can comfortably map 1 line of code into hundreds of SQL queries on the back end. N+1 problem anyone? JPA and others are extremely similar in achieving this act of insanity!
XRebel focuses heavily on database queries by understanding how many queries are executed on a single request, as well as how much time each query takes. The UI will group common queries together and even show you the exact SQL which is being drive and the culprit code behind the call.
More Proactive & Less Reactive
Basically this is about the split of those who only profile their code when a problem occurs and those who profile their application every x days, weeks, months, irrespective of whether there’s a known problem or not. The difference is clear from the survey results, that it’s much better to test regularly and you will find more issues.
XRebel is more than testing regularly. XRebel is about testing all the time. The always on profiler in a development environment is so lightweight that it sits in the corner of your application waiting for issues to arise, at which point it will notify you.
So, Maybe I should check out XRebel!
As a Java Developer trying to avoid any major performance mea culpas in your code, you should definitely check out XRebel. XRebel, the lightweight Java profiler, helps Java developers test early, be proactive and keep on top of potential database issues. As one of our developers puts it “you will finally understand what the hell is going on in your code”!:
- Application profiling. Ever wonder what is happening with each individual request that your app is making? With XRebel you can find the slowest methods that may slow down your app in production and cause issues. This happens as you code, you can see alerts in a widget in your browser.
- Profile JDBC and NoSQL databases. As the report mentioned, looking after your database is important. Would you like to be able to identify excessive database calls easily? XRebel finds methods that initiate too many queries and locates the root cause with a hierarchical view and connect SQL queries to the call stack for JDBC and for noSQL databases including MongoDB, Cassandra, HBase and Neo4j to help you better understand your queries.
Check out XRebel and see what I mean for yourself try out XRebel I would love to hear your feedback on XRebel and also other suggestions on how to address some of the recommended best practices from the report.