Tag Archives: website

There are many tools to use for web performance testing, but if you want a good tool that does the job, I recommend Jmeter. The good and bad thing about JMeter is that there are alot of different options and features. To make it simpler for you, the good folks at Digital Ocean have a good tutorial on getting it set up, here: How To Use Apache JMeter To Perform Load Testing on a Web Server | DigitalOcean. While this is fine for testing one page, there are test scenarios where you want to have the user perform multiple steps (e.g. go to the home page, login to their account, check their account balance, then logout). If that is the case for you, too, then you want to read this next: How To Use JMeter To Record Test Scenarios | DigitalOcean (I used Firefox for this: if you are going to use JMeter to develop your performance test cases, then download Firefox too.) For any performance testing that follows a sequence, you really want to use the recording feature of JMeter.

Some other thoughts….

On my thread group, I added the following listeners:

• Response time graph
• Graph results
• Aggregate report
• View results tree (with scroll automatically on)

I also login to the web server and tail -f  the access log (and sometimes the error log).

I do all this because it is easy to run have a lot of errors when you first (and even later) run your test. For example, if you are testing a sequence, you might see good performance, but you might also see 404s in the access log, or you might see other anomalies in the aggregate report (e.g. good response 90% of the time, but bad response on average). Having more data is better and it insures you don’t have false positives (e.g., you think performance is good, but it really isn’t because the application is failing).

As soon as your developers have some code in place, have someone run Jmeter against it. Don’t wait until towards the end of the project. Jmeter is free and anyone can use it.

Back up your test plans often. It is easy to change your test plan, have it go from a successful one to an unsuccessful one because of the change, and then find it hard to go back because you changed a number of variables.

For your test plan, have multiple thread groups. This will allow you to test different test scenarios for different test groups. You can have different test plans too: it’s up to you how you manage it. For example, I recorded a long sequence for one test group, then I copied it and made a simple test group with less steps by removing them.