So how would I decide on which method to implement? Well, lets just chose the one that performs the best. Ok, how do I do that? Hmmm. I could download and install some of the tools out there, or I could just wrap the shell code in a function and add some timings. OR, I could use the same tool that I use to performance test everything else; JMeter. To me it was a no brainer.
So how do we do it?
There is a full tutorial here.
Simply put, you need to do the following:
- Create a Sampler class.
- Create a BeanInfo class.
- Create a properties file.
- Bundle up into a jar and drop into the apache-jmeter-X.X\lib\ext folder
- Update search_paths=../lib/ext/mongodb.jar in jmeter.properties if you place the jar anywhere else.
How I did it
I tend to have a scratch pad project set up in my IDE, so I decided just to go with that. Just to be on the safe side, I imported all the dependencies from:
- apache-jmeter-X.X\lib
- apache-jmeter-X.X\lib\ext
- apache-jmeter-X.X\lib\junit
I then created the two class and the properties file.
I then exported the jar to apache-jmeter-X.X\lib\ext, and fired up jmeter.
Go throunullgh the normal steps to set the test plan up:
- Right click Test Plan and add a Thread Group.
- Right click the Thread Group and add a Sampler, in this case a MongoDB Script Sampler.
- Add your script to the textarea; db.YOUR_COLLECTION_NAME.insert({“jan” : “thinks he is great”})
- Run the test
Happy days. You can then use JMeter as you would for any other sampler.
Future enhancements
This is just a hack that took me 37 minutes to get running, plus 24 minutes if you include this post. This can certainly be extended to allow you to enter the replicaset config details for instance and to pull the creation of the connection out so we’re not initiating this each time run a test.
Reference: Performance testing MongoDB from our JCG partner Jan Ettles at the Exceptionally exceptional exceptions blog.
