An essential element of the controller or agent is the load generator that handles request /response processing. It needs a sufficient number of .NET threads to timely send and process HTTP messages.

The system creates the necessary number of threads automatically, depending on the test complexity, the number of VUs and the test machine’s capacity.  The actual number of threads allocated to StresStimulus process is controlled by the operating system, and depends on the load generator's needs to issue requests.

By default, before the test begins, StresStimulus allocates the number of .NET threads threads equal to the maximum number of VUs expected in this test.

During test execution, one VU may consume more than one thread to handle parallel requests. If StresStimulus needs more resources, the OS will gradually increase threads to the sufficient level. On some systems, however, OS fails to ramp-up threads fast enough.  This may result in delays in issuing requests after receiving a response at some moments during the test execution. You can check if such delays exist in your system by analyzing a page or transaction waterfall chart.

If you see a gap between the moment of receiving a response and issuing a subsequent request, your system may need more threads.  To address the situation, you can manually adjust the initial number of threads, which is a property of a load agent.



Note: The gap between a response and a subsequent request can be caused by different reasons. For example, StresStimulus intentionally delays subsequent request to comply with the emulated browser characteristics. Each browser type has a limited number of connections-per-host and connections-per-proxy. When the number of connection exceeds this limit, StresStimulus will pause requests to realistically mimic a physical browser behavior.



If you need to ramp up threads faster, which may be necessary when running large-scale tests on high performance hardware, set the Minimum starting threads property to the level 120%-150% of the number of virtual users. That should boost the performance of your load generator. After that, rerun your test to check if such an increase was sufficient. You might need to try several different numbers until your load generator receives sufficient resources. This property is configured for each load agent individually. Note that setting a too high number of threads may leave insufficient resources for the OS and can slow down your computer.

Info: One VU is not equal to one thread. Threads available to the process (thread pool) can be used by different VUs at different times. Each VU can issue multiple concurrent requests (connections), depending on your test case and the connection limit of the selected browser. For example, IE9 can open up to 6 connections.

Note: In the previous versions, the thread allocation algorithm relied on .NET Framework's default algorithm of allocating threads. As a result, the starting thread count was typically smaller than the number of virtual users. For backward compatibility, the option to use the legacy thread allocation algorithm exist. To use it, set property Allocate at least one thread per VU to No. 



Typically the load engine is optimized for performance to handle the more virtual users on a single load generator. However, if your test has many resource requests that have a small expected response time want to change the load engine optimization for "Time Resolution". This will enable measuring response times under 0.1 second with more precision, however, will have a performance impact with more virtual users.



  • No labels