London-based start-up jClarity has announced the general availability of their flagship product for locating Java performance problems in both Cloud and Enterprise environments.
Founded by three Java gurus Ben Evans, Martijn Verberg and Kirk Pepperdine, jClarity first released their Censum Garbage Collector analysis tool last December, as reported on InfoQ.
jClarity says their current customer base includes Google, VMWare, and BNP Paribas, among many others.
The new tool is low profile and can be installed on both Cloud-based and Enterprise systems. One of the distinguishing factors between this and other performance monitoring tools is the simplicity of the reporting of issues and suggested solutions in plain English.
InfoQ spoke to jClarity's CEO Ben Evans about the product and the release.
InfoQ: There are lots of Java performance tools out there, what distinguishes jClarity?
Ben: jClarity provides deep analysis of problems, rather than just data. This means that the insight that an engineer gets into a problem is much deeper. The jClarity user experience has been designed so that QA teams, managers, operations teams and developers can share the same easy-to-use view of a performance problem - framing the conversation and providing better information to enable faster, better resolution management decisions.
Most tools are fairly obviously native to either the Cloud or Enterprise. jClarity can do both use cases, and runs in both PROD and QA, as the analysis capabilities go beyond APM and into automatic fault detection and project risk reduction.
InfoQ: How does an engineer use it?
Ben: For cloud deployments, the jClarity collection agents are installed onto every host which is running an application JVM, and report back to the jClarity performance console. For the enterprise, we can deploy completely behind the corporate firewall, including the web console.
InfoQ: You say it can run in production environments?
Ben: jClarity runs in production, and provides great feedback on production problems. We also run very well in QA or performance-testing environments, and many of our customers find that by deploying in QA they can find and fix problems long before they get anywhere near a live customer.
InfoQ: What is the performance impact of having the tool running?
Ben: Most of the time zero or near zero. The jClarity collection agents remain quiet until they are triggered, either by some external event, or by an explicit diagnosis command. The diagnosis process last for a few seconds at most, and then the agents go quiet again.
InfoQ: What is your pricing model?
Ben: jClarity Basic is free for 14 days. After that - $24 per cloud server per month (discounts available for annual contracts or large orders). Enterprise pricing is based on application; if you would like to give it a try please contact sales@jclarity.com.
InfoQ: Is there anything else you would like to mention?
Ben: jClarity runs on any JVM-based application - not just Java. If you're a Scala or Groovy or Clojure shop - no problem. Come and try out jClarity - it's easy and free to try it out - and lots of our initial users have told us that it can find problems straight-away.
Finally, we'd like to give a big shout-out to our awesome community - the Friends of jClarity. This group of Java and performance professionals have provided so much great feedback, use cases and thought-provoking discussion over the last year. They've validated and challenged us, and we feel proud to have a community like that as our customers and peers.
A free trial is available for download at http://www.jclarity.com.
Here are some screenshots illustrating a simple workflow for location performance issues using jClarity:
Figure 1 - The jClarity console: From here, we can see the collection agents that are online and under management. The time of the last diagnosis is displayed, and a simple scheme of icons (including hardware/OS, garbage collection and Java application code) are displayed which show potential problems:
Figure 2 - Clicking on an individual diagnosis result brings up full details of which JVM process is affected, and an immediate description of the problem that was automatically found (in this case, a thread deadlock):
Figure 3 - The console automatically saves past diagnosis results, allowing all stakeholders to see the same details as when the problem was initially identified - providing a focal point for the conversation about how to fix the issue:
