In order to run load tests with WebSurge it's important to understand how WebSurge groups together a set of requests and executes them.
There are a few important concepts to understand:
A session is represented by the full request list in the WebSurge UI or the JSON configuration. It is a set of requests that are executed one after the other by a Load Test or by Run All Requests.
Threads are the number of simultaneous sessions that are executed in parallel when running a Load Test.
Each thread is tied to a User which defines an Http Execution Context. A User holds some stateful context like Http Cookies, a shared Http connection and optionally custom values like captured Form Variables or JSON Tokens that can be reused in later requests in the same session. It can also hold custom operations like Login Urls that can provide user specific credentials as well as per request capture of form variables and JSON tokens.
These can be configured via User Session settings that allow you configure specific user state that will be used for any given session that is assigned that user.
In summary Sessions, Threads and Users are associated like this:
- Many threads run many sessions simultaneously
- Each thread maps to exactly one session
- Each thread maps to exactly one user
- But: Each session can map to multiple threads and users
- There can be more threads than users or vice versa
The basic unit of a load test is the thread that ties together the session and the user. The key point is that a thread maps exactly to one session and one user that maintains the same Http execution context. What this means is that the Http request state for a thread is always the same so things like cookies, token and authentication values can be maintained across requests.
Important: Http state is reset only at the beginning of a test. So once a Cookie is set or a request value is captured that value remains set through the test run for subsequent request, for that particular thread and session.
Users are created:
If you don't provide explicit users, WebSurge creates a generic user for each of the threads in the test.
You can explicitly create users via the WebSurge Session Configuration which allows you explicitly provide explicit login urls and credentials or other form variables at specific URLs. This allows customizing sessions for specific requests on a per user basis (typically for authentication).
If you create fewer users than the number of threads for a load test, the provided users are evenly distributed across the number of threads which means that multiple threads may use the same user. Ideally if you configure custom users you'll want to match the number of users to your number of threads if it's important that each user has a truly unique session. Otherwise Users may be reused across multiple threads which may result in unexpected user state.
The following topics cover setting up of individual user sessions, as well as generic directives that let you capture authentication information and reuse it in later requests.
Comment or report problem with topic