Or for the benefit of Google: Apache JMeter versus The Grinder. Fight!
A while ago I got paid to put these two tools head to head and I think it’s been long enough that the people who put up the money will have got the benefit now.
I had used The Grinder in a previous job where it had done excellent service finding out what level of peak load our site could handle. It was convenient in that you script it in Jython because Jython was our chosen scripting language.
JMeter on the other hand was a whole new thing to me. It is a kind of graphical programming interface where you drop controls into a tree structure and the framework generates threads that run through the tree generating interactions with the target application via things like HttpClient.
The scripting versus component structure is a pretty major difference between the two and is probably one of the key things that is going to help you choose between two products that are both, to be honest, pretty mature, capable pieces of software.
Another big differentiator is in reporting, if you need to generate reports then JMeter is a much better choice as it has components that collect and collate information and you can dump data to XML for XSLT transformation into pretty much any output format you want. It is also possible to run JMeter headless once you have the test scripts so it is possible to encorporate it into a continuous integration process. Debugging slightly flaky applications is much easier with JMeter because you can easily capture a lot of result information and then just delete the data gathering component once the test flow is working.
A lot of the functionality of both products overlaps: they can both be used a browser proxy and be used to capture scripts as a user “drives” around the site. These captures are likely to form the basis of your test plans unless you have a very clear URL scheme with little session state.
Both use thread pools to generate load and both tend to get blocked on your application before they max out their local machine (although both are capable of using 90% of memory and CPU). JMeter has a few nice options around randomly ramping up the thread activation (recreating a spike in usage more closely). The Grinder tends to give more bang for the buck as its runtime is very simple and minimal.
Both are also capable of using distributed agents and collating the data from these agents back to the coordinator.
In many ways there isn’t a “bad” choice to be made between them. So what might sway your choice one way or another? Well JMeter is an Apache project and that might make a difference for some people as you have all those good things like project governance and a good chance the project is going to continue to be developed and enhanced. JMeter was also the only project to have a test suite last time I checked out both code bases.
The Grinder does have one unbeatable quality in my opinion and that’s flexibility. When you look at the features listed on the websites you might think that JMeter does all this cool stuff with HTTP, SOAP and POP3 and the like and that The Grinder is comparatively light in the feature set.
The opposite is actually true, as The Grinder website points out the The Grinder can test anything with a Java API. There really is no limit to what you can make it do or how you can execute your test plan. In fact most of the things I’ve complained about with The Grinder are fixable from within the test scripts (what I am really complaining about is that some things like capturing HTML output per run is something that should be available as part of the standard package). On the other hand I felt that creating a new JMeter component was actually quite tricky as you have to deal with both the GUI aspects and the actual functionality you are trying to create in your test component.
If you really want to have total control of your concurrent volume testing then The Grinder is probably the best product for you.
Perhaps the last topic for consideration is The Grinder’s use of Jython. Python is a great language and you get a lot of power for some very concise code. Just as some people are going to find it off-putting others are actually going to find it very compelling.
Okay so yet another weak “horses for courses” post on the InterWeb. Perhaps the easiest summary to end on is that your test teams will probably take a shine to JMeter while your developer teams who are also building scale tests are probably going to like The Grinder; unless they dislike Python or learning a new language.
13 thoughts on “JMeter or The Grinder, so which one is better, like?”
I’ve just stumbled across this. Good comparison.
I’d like to correct one point. The Grinder has always had an extensive unit test suite. 760 tests with 83.6% coverage of a substantial code base, and rising. http://grinder.svn.sourceforge.net/viewvc/grinder/trunk/source/tests-src/
very well written comparison. thank you.
Yup, good comparison!
I just want to add that the GrinderStone Eclipse plugin allows to debug and create Grinder scripts in a fast way. Check it out from
Very Interesting. Thank you!
You can also integrate HttpUnit into The Grinder of course so it is not a massive distinguishing point until there is a pre-built HttpUnit sampler.
Pingback: Bookmarks for February 23rd through February 27th | Peng's Blog
Hi great explaination many thanks but i have a little question does the Grinder provide Manual testing ?
No it doesn’t. It is really all about the script execution.
Very good comparison. Thanks for sharing the knowledge and experience.
Still a very useful post in 2014. I’m new to load testing. Thanks.
Thanks for a great review. In my turn I would like to share more recent post which does a comparative review of JMeter, Grinder, Gatling and Tsung. Check out Open Source Load Testing Tools: Which One Should You Use? guide.
I would always prefer The Grinder over JMeter because it takes a scripting approach which allows you to basically do anything that you could do with Java. Now I know a lot of people must be put off because they think they have to learn clojure or Jython to go with The Grinder. I was however able to write all my tests in Groovy/Java in a Maven Project and run load testing scripts. All you need to do is find the maven dependencies for The grinder console and client and write your code in pure java ( or any jvm language that can be used in a maven, gradle project)