March 21, 2004

The Grinder

I did some performance testing against a web application that I helped write this weekend. I used The Grinder and was quite happy with the beta version. This lets you write scripts in Jython and uses the quite nice HTTPClient library. The Grinder, like most other performance tools, has an admin interface (the console) and a set up distributed agents that are given tasks and communicate results back via the network to the console. I used the HTTP client, but it looks like you can 'grind' anything you can talk to via java, from databases to email servers.

I did run into a few problems. I'm using cygwin on WinXP, and had some difficulties running java from the command line. The fix was to use the cygpath command, like so:

#!/bin/sh
# to start the agent
JAVA=/cygdrive/c/j2sdk1.4.2_03/bin/java
CLASSPATH=`cygpath -p -w /home/Owner/work/grinder/grinder-3.0-beta20/lib/grinder.jar:\
/home/Owner/work/grinder/grinder-3.0-beta20/lib/jakarta-oro-2.0.6.jar:\
/home/Owner/work/grinder/grinder-3.0-beta20/lib/jython.jar`
$JAVA -cp $CLASSPATH net.grinder.Grinder

The client application that I was testing doesn't use cookies (it's a J2ME application, and the MIDP spec doesn't support cookies out of the box). Or rather, it uses cookies, but only to grab the first one that the server sends, store it off, and then pass it back as a query parameter. This type of configuration isn't The Grinder's sweet spot, and I had to do a bit of hacking to make sure the appropriate cookie value was sent with the appropriate client request. It would have been nice to use contexts but The Grinder wraps the HTTPConnection in its own class. Apparently, if you are simulating use by a browser, cookies are apparently handled correctly. One gripe--there's no javadoc for the main classes available on The Grinder's website, so you have to grab the source if you want to see interactions between pieces (for example, how net.grinder.plugin.http.HTTPRequest interacts with HTTPClient.HTTPConnection).

I also mucked with some of the properties, primarily initialSleepTime. You'll want to make sure that you read about these properties--I blithely uncommented what was in the sample grinder.properties and ended up with an obscene value for grinder.sleepTimeFactor.

After all the setup, I was able to hammer our server. I discovered two useful things: an error in our logout code, which threw exceptions around 10% of the time, and also discovered that our connection timeout between Apache and Tomcat was set incorrectly. Changing this from 0 to 1000 fixed the dreaded SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status error that I was getting. In addition to these two useful bugs, by making some assumptions about how the application will be used, I was able to gimmick up some interesting numbers about supportable users.

I like The Grinder a fair bit. It's got a nice GUI. It's still under active development. I'm a bit leery of using beta software (especially open source beta software), but a poll on the homepage convinced me to try the beta. By using this, I was also able to pick up snatches of python which is a new language to me (finally got to consult my long unused copy of Learning Python). I considered looking at JMeter, but The Grinder appears to be a bit more recently maintained. It's no LoadRunner, but then again, it doesn't pretend to be. All in all, if you're in the market for a cheap, quick performance tool, The Grinder is worth a look.

Posted by moore at March 21, 2004 12:57 PM
Comments

Besides JMeter's lack of maintaince is there any other strong reason for using Grinder? Do you feel that if users know JMeter they should switch?

Posted by: Kris Thompson at March 22, 2004 08:30 AM | Permalink

From looking at JMeter, it appears to have a much nicer user interface both for building tests and displaying results. You can build a test visually, which is something that The Grinder just doesn't let you do (at least V3--I don't know about The Grinder V2).

The big plus of The Grinder is being able to use jython to write arbitrary tests. Consider, on the other hand, JMeter, where, if you don't want to do one of the supported actions (here: http://jakarta.apache.org/jmeter/usermanual/test_plan.html#samplers) , which cover, granted, everything I'd want to do in a test, then I'm not really sure what you'd do. In the example above, I was taking the value of a cookie and setting a query param based on that value, and it's not clear to me how I'd do it in JMeter.

I also don't see POST support in JMeter, whereas The Grinder definitely has that (http://grinder.sourceforge.net/g3/script-gallery.html#fba).

Also, JMeter seems to be built for use from a single computer, though it does explicitly have support for remote agents (http://jakarta.apache.org/jmeter/usermanual/remote-test.html). The Grinder is set up from the start to have the differentiation between agent (data collector) and console (data displayer). This is a small difference.

Again, I haven't used JMeter, this comment is just based on reading the documents at the JMeter site.

Posted by: Dan Moore at March 22, 2004 09:41 AM | Permalink

We have downloaded the source code Grider3 (beta version) but the grinder.jar file is missing (the entire Lib folder itself is missing). Please suggest a solution for the problem.

Posted by: Krishna at April 6, 2004 06:00 AM | Permalink

Hi Krishna,

What files did you download? I just got the grinder from this url:

http://easynews.dl.sourceforge.net/sourceforge/grinder/grinder-3.0-beta21.zip

and there's a lib dir and a grinder.jar in it.

Dan

Posted by: Dan Moore at April 6, 2004 10:36 AM | Permalink

The following error is displayed when
java net.grinder.Grinder is given

Error initialising grinder process: net.grinder.common.GrinderException: Mandato
ry property 'grinder.plugin' not specified
net.grinder.common.GrinderException: Mandatory property 'grinder.plugin' not spe
cified
at net.grinder.common.GrinderProperties.getMandatoryProperty(GrinderProp
erties.java:159)
at net.grinder.engine.process.GrinderProcess.instantiatePlugin(GrinderPr
ocess.java:253)
at net.grinder.engine.process.GrinderProcess.(GrinderProcess.java:
215)
at net.grinder.engine.process.GrinderProcess.main(GrinderProcess.java:10)
The Grinder version 2.8.6 finished

Inputs reqd?

Posted by: Sailaja at April 23, 2004 06:54 AM | Permalink

Jmeter does have POST support. It's selectable on the HTTPRequest component. I have been able to get jmeter to do pretty reasonable stuff like hit a home page, log in as a user with a post, cycle through some account history pages using regexes to pull out urls. You can then loop all this with different users. I'm interested in taking a look at grinder.

Posted by: roobeast at April 27, 2004 12:09 PM | Permalink

Hi Roobeast
Could you please tell me how you "loop all this with DIFFERENT USERS"?

Thanks a lot

Posted by: windy at May 12, 2004 10:01 AM | Permalink

same problem as sailajabatchu@yahoo.com

Mandatory property 'grinder.plugin' not specified

any hints?

Posted by: TP at July 6, 2004 09:34 AM | Permalink

Hi TP,

So, there's a file called grinder.properties that needs to be in the classpath of the agent scripts. For the Grinder v3 (which is what I used) I didn't have to have a grinder.plugin property, but I did have to have the grinder.properties file. If you're using v2, perhaps http://grinder.sourceforge.net/manual/properties.html will help you out. From http://grinder.sourceforge.net/manual/http-plugin.html, it looks like the grinder.plugin property needs to be set to net.grinder.plugin.http.HttpPlugin

Posted by: Dan Moore at July 7, 2004 09:05 PM | Permalink

Where does the grinder.propeties file nedd to be placed ???

I think it is not finding it when running the agent.

Posted by: Rodrigo at July 23, 2004 03:16 AM | Permalink

I am using grinder2.8.1 aftr getting into a mess trying to use jython and the plugin files. grinder2 seems to be working perfectly fine, but i am encountering a problem in hitting our test site. We r using cookies based authentication and i tried to use the HTTPSniffer for setting the username and password as post parameters. But I am always getting a '302 redirection message' as the output. I am displaying the output by manually inserting sops in the grinder source code. I saw something like authenticationrealm , username and pwd as grinder properties. Could you help me out in setting the correct configuration?

regards

Posted by: alex at August 4, 2004 10:07 PM | Permalink
© Moore Consulting, 2003-2006