Getting an application to its peak performance requires a load testing phase. When the web servers and database servers are all setup and ready for production you should run a test that simulates the number of users you expect. You should also run more tests to determine the system’s max capacity.
Max capacity testing is more fun. Jmeter has tons of features to perform these tests. It written in java and isn’t the easiest tool to use so I will walk through a basic website test.
After you install java and download jmeter (http://jakarta.apache.org/jmeter/) open up the bin/jmeter.bat. The first thing to do is add a couple of items to our test plan. The first is a thread group that will allow you to group together the actual tests or “samples”. We’ll also want to view the results. To do this add a “summary report” item to your test plan.
Now we can start adding HTTP request samplers. The only thing you have to change is the Server name and the path. For my blog that is dustinandmandy.dyndns-home.com and wordpress.
Once you add a few different HTTP requests with different URLs select the thread group. Check the Forever box next to loop count. Here you can also edit the number of threads. Threads is a setting you will keep coming back to later but for now 1 thread or “user” is good.
The test is set but we want to save off the results in a readable format. Go to summary report and click browse and type in a .csv path and filename. Click configure and check these items as I have found them useful in website load testing:
1. Save Response code (200, 404, 500 etc.)
2. Save Time Stamp (when the test started)
3. Save Field Names (to help sort and filter the .csv)
4. Save Latency (perf data)
5. Save Elapsed Time (perf data)
6. Save byte count ( useful to compare size to time )
When I started out I always saved XML output. You have a couple more options such as saving all of the HTML response data but it adds a couple steps to analyzing the output. I actually wrote a quick program to parse the latency timings and response codes out of this xml into a .csv. That proved a waste of time once I figured out jmeter could do that 🙂
The summary report pages is where you can watch the results poor in as your run the test. Ctrl+E clears the results (but not the results file). Ctrl+R runs and Ctrl+”,” gracefully shuts down the tests. Ctrl+”.” sends a reset which stops the tests instantly but will give you errors in your results for any open threads.
Run a few tests a take a look at the results. Once you make sure you are getting all 200s you can tweak the number of threads. What jmeter does is opens “n” HTTP connections and sends the request, as soon as a response is received another HTTP request is sent. This isn’t a normal users pattern. Normal users will have a delay while they read each page. Depending on your content you may assume that users will spend about 10 seconds on each page so to test for 100 concurrent users you only need 10 concurrent threads (threads = users / time spent on page).
What you want to do is keep increasing the threads until you start receiving server errors or see diminishing returns in the number of samples you can get through in a particular amount of time. If you check the scheduler box you can set a test duration. This would be a full capacity test. Keep an eye on the servers CPU %, Network Utilization, Memory and Disk metrics. Also, watch your test computer’s metrics. What you might find is that a desktop with a 100MB nic is actually the bottleneck in the test. If this is the case you can run the test simultaneously from different computers. You may be able to have 100 active threads but with only 1 core you are not really testing concurrency to the best of jmeter’s abilities. You can definitely max out servers with one testing box and 100 threads but you will get more accurate capacity number if you have 100 testing boxes with 1 thread.
Jmeter is a very useful tool to have in your toolbelt. Use it to help work out all the kinks before you go live.