When stress testing software, it is desirable to know if the software is actually being stressed. To know this we must first define what is meant by stressed. For the purposes of testing, a system is stressed when the rate at which operation against a system can’t be increased and the rate is not being limited by resources used by the test itself. This means that if resources used by the software being tested are at their limit, the software is (usually) being stressed. Usually is mentioned since some resources might not serve as a limit to operations directly. This can be the case for caches, as hitting cache limits might not mean the system can’t handle more load. (Although hitting cache limits is usually a good sign that one is on the right track.)
Since there are multiple different ways most software can be used, there are multiple different bottlenecks that could be hit. Something that goes over a network could easily hit network limits for certain types of workloads and disk limits for others .
To know if resources are being limited, we need to be able to measure the resource. Windows provides a good method of monitoring system resources through perfmon. Perfmon has counters for various system resources (such as cpu, memory or disk). Each resource typically has multiple counters so the resource can be monitored in various ways. Applications can register their own perfmon counters, which allows a test to get even more information about what is going on. This could be of interest if there are hard limits on internal objects used by the software being tested that would not reflect on the system level counters. For example, a database could hypothetically limit the number of outstanding transactions to two. If this limit was hit there would few system resources being used, but the software would be stressed.
Perfmon data can be checked manually while a test is being developed and at points during the lifecycle of a test. Another approach is do use the perfmon APIs to gather this data automatically and log it, allowing this data to be inspected with the rest of the test results.
Task manager can also be used to get a ballpark estimate of system load, although less information is available and far less history is available. It is useful as a quick spot check.