February 25, 2021
Hot Topics:

Performance Improvement: Understanding

  • By Rob Bogue
  • Send Email »
  • More Articles »

Load Testing and Stress Testing

Watching performance numbers when a system is idle is like watching a pot waiting for it to boil—when you've not turned on the stove. Performance numbers are important things to watch but only when the system is active. If the system isn't active in some way there's nothing to watch. That being said, what do you do when you don't have real users on the system—or the next revision of the system—yet? The answer is a category of tests called load tests. In this set of tests you create artificial load on the system to measure the performance, the scalability, or determine the most likely points where the system will break.

Load testing which is often used to describe the broad category of tests is specifically the generation of user simulating load on the system. The fact that load tests are supposed to simulate the user is the largest part of the problem with the load testing concept. It presumes that you can break user behaviors into repeatable patterns which can be run over-and-over with some randomization of the data being used—and that you can estimate what percentage of the users will be following each of the different paths that you choose. The problem with this is that if you get the workloads (behavior patterns) wrong you end up with a test that isn't valid. If you get the balance between workloads wrong you end up with a test that isn't valid. In order to get a set of numbers you can reasonably rely upon you’ll need to run different workload mixes against the platform and compare the numbers to see what might happen if your guesses are wrong.

True load testing, often called scale testing, is very difficult to get right. Not only do you have the challenges with estimating user behavior—particularly if you have no baseline data to work from—but also because the implementation in the tooling isn't the greatest. Creating a load test generally involves recording a set of interactions and then going back and adding the data sources behind it. In other words, you record your clicks as you navigate to each page in a site and then go back later and manually add data sources to control those clicks so they don't hit the exact same pages over and over again. This is important because caching will have an unusually large positive influence if you keep hitting the same few pages. As a result the work to generate the load tests is pretty tedious and extremely fragile. If you change the user interface even slightly your load test scripts may need to be regenerated from scratch.

A variant of the load test is a performance test. In this case you're not concerned with the scalability of the application you're concerned exclusively with the performance (or responsiveness) of the application to the user. In this case you can simply record a script and review the responsiveness of the web site to the inquiries. This can be done with and without various artificial loads. This will provide some level of understanding about how the system should perform. It should be noted that often times loads interact with one another and so considerations should be made to test mixed loads.

The final type of load testing is called stress testing. In this kind of testing the objective is to break the system. Stress tests are designed to make the system work as hard as possible to see how it breaks. Sometimes web sites break completely when heavy loads are applied. Other systems simply slow down until their responsiveness isn't something the users would tolerate. The goal would be identify and resolve any parts of the application which cause the site to literally break. This is particularly true for any parts of the application which would require that the administrator to reset things to get them operational again.


Performance isn’t the deep dark scary secret that some folks make it out to be, however, it’s also not an exact science either. With some understanding of how systems work and how to measure the impact of software on systems you’ve got a foundation for making some decisions to test performance and develop better performance. Our next stop on our quest for performance improvement is session state since it can have a huge impact on overall performance.

About the Author

Robert Bogue, MS MVP Microsoft Office SharePoint Server, MCSE, MCSA:Security, etc., has contributed to more than 100 book projects and numerous other publishing projects. Robert’s latest book is The SharePoint Shepherd’s Guide for End Users. You can find out more about the book at http://www.SharePointShepherd.com. Robert blogs at http://www.thorprojects.com/blog You can reach Robert at Rob.Bogue@thorprojects.com.

Page 3 of 3

This article was originally published on June 29, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date