JMeter as testing tool for Spring app

[kantorn]

Hi

Are there anyone who have experience in testing a Spring-based webapp using JMeter?

I wonder how to test submitions to forms as Spring handles those things in a special way. It's very seldom you actually parse the request parameters on a submission, they are instead bound to the form data object.

Are there a better way of load testing a Spring app?

Interested in all kinds of experience.

[gmatthews]

We used jcrawler to do some quick and dirty load testing.

If people will be primarily viewing pages as opposed to filling out forms and clicking submit then jcrawler may give you useful information.

Our app probably gets 40 pages views to every 1 form completion so the fact that we weren't simulating filling in forms probably only makes a small difference.

The great thing about jcrawler is that you just give it a starting URL and away it goes.

[Ben Alex]

I recommend http://grinder.sourceforge.net/ version 3 for pure stress testing, and http://jwebunit.sourceforge.net/ for functional testing (it wraps HttpUnit and makes it easier to deal with).

[Chris]

I have used jMeter to load test the jPetStore example application. Since in this case jMeter deals in HTTP requests (get or post), it is totally un-aware of what app server or framework is processing the requests. If you like I could email you the jMeter config file I used.

[Rod Johnson]

I wonder how to test submitions to forms as Spring handles those things in a special way. It's very seldom you actually parse the request parameters on a submission, they are instead bound to the form data object.

As Chris points out, nothing Spring does affects what load testing tools you can use.

And Spring's data binding approach is not unusual: other frameworks use the same concepts. It just saves you work, rather than changing anything publically exposed in your web app.

[kantorn]

I have used jMeter to load test the jPetStore example application. Since in this case jMeter deals in HTTP requests (get or post), it is totally un-aware of what app server or framework is processing the requests. If you like I could email you the jMeter config file I used.

I would be very grateful if you could do that.

[spring04]

Hi Chris,

Have you used jMeter with any other non-web application. Did you use the graphical interface provided by jMeter or the command-line interface? We would like this load test to run as part of our nightly build.

Thanks!

[Chris]

I have tested a simple Java class by extending the following jMeter framework class, this worked well. I did not however execute this from the command line.

http://jakarta.apache.org/jmeter/api...lerClient.html

Instructions for execution of jMeter from an Ant task are here:

[/url]http://wiki.apache.org/jakarta-jmeter/JMeterFAQ#head-9f8a07a9e4bbc875fca60c3be01755ff3c1e6103[/url]

Kantorn - the jMeter config file is 57kb, this seems a little large to paste in here. If you email me I will reply with the file.

[kantorn]

Thanks for all replies, I appreciate it!

I've read about load testing webapps a bit, and there seems to be some disagreement if it is really possible to load test a webapp with 100% accurancy.

Say for example that a requirement says that a page shall be able to handle 100 concurrent requests. But when blowing upp 100 threads from a testing client other things come into play, like network latency, caching, queuing of the requests on the server, limitations in the client machine, etc. etc.

So my question is: can you be really sure that an app has met the requirements just from load testing with some tool that allows this?
What is your opinion / experience?

[Ben Alex]

Most of these tools allow you to run from multiple client machines, and if you're in a test lab type setup you'll generally find a standard 100 Mbps (or Gigabit) switch between the boxes overcomes most of the network latency issues.

In my real-world experience, the major bottleneck with such stress testing setups is the "server". Specific issues that drag down performance (aside from the app itself) include the server doesn't reflect production specs; it has the RDBMS colocated with the servlet container; and the RDBMS has been setup by developers instead of a DBA (an RDBMS is a specialised, complex product and deserves the expertise of people who understand its inner workings).

Also, some consideration must be given to whether to allow user think time between each request, and whether to randomise the think time to reflect actual user behaviour. You can increase the reported performance of your application by several orders of magnitude by the simple decision of how to handle user think time. Don't forget to plot servlet container memory usage over a really long period (like 72 hours) running the tests. Sometimes developers don't tidy up their Collections (eg they key some workflow/password/token/whatever against a HttpSession ID but forget to tidy it up at HttpSession expiry) and this helps identify such issues before they hit production.

I'd strongly urge everyone to do stress testing for non-trivial applications. Issues like latency are rarely of material impact on your test performance, at least compared with things like server hardware specs, RDBMS configuration, how your app actually behaves (you're using lazy loading, right?!) etc.