To send an HTTP request, a connection must be established to the server. During the load test execution, every VU creates multiple connections to the Webserver(s) being load tested. 

There are several steps required to create a new connection:

  • Establish a connection
  • DNS resolution
  • HTTPS handshaking (if applicable)


Creating a connection consumes some system resources. In some cases, the performance impact of creating connections can be significant. If too many connections are created, then the performance of the test machine degrades, which may impact the accuracy of the test result. To save resources on maintaining connections, connection pools are used to reuse connections for subsequent requests.



There are two ways to handle connection pooling in StresStimulus:


  • Per VU: Each VU has its own connection pool with its own DNS cache. On the first request to every host, DNS resolution takes place, and then it is cached in the connection pool. This behavior of a VU accurately emulates the behavior of a physical user when every user conducts its own DNS resolution. Use this option when You need to accurately estimate DNS resolution time in your performance tests and when system resources are sufficient. While providing accurate DNS resolution emulation, this connection pooling model requires more hardware resources, as the number of connection pools will equal the number of VUs. This pooling model should be used when the number of VUs is not too high or when the load generator machines have sufficient resources. To enable Per VU Pooling, in the workflow tree, go to Advanced Options and change the Use a shared connection pool for all VUs? to No. 

    Note:

    Use this option when authenticating with client certificates. For more information see Authentication.


  • Shared: There is a single connection pool that all VUs share. This model consumes the least amount of system resources and works best in large-scale tests. The only disadvantage of this model is that DNS resolution is performed once per host for all VUs. For practical purposes, DNS resolution time, in most cases, is an insignificant comparison to application server response time and network latency. Therefore this pooling model should be used in most cases as it provides the best load test scalability. It is enabled by default.

  • No labels