Session, Threads and User Management

In order to run load tests with WebSurge, it's useful to understand how context is managed when many requests are executed simultaneously. This topic provides an overview of terms and discusses how Requests, Sessions, Threads, Users and Http Context management interact with each other.

For more specific content, please see these topics:

Session and User Terminology

WebSurge uses several abstract terms to describe the concepts of how load tests manage context and state when running many requests simultaneously.

Request

Requests are the base unit for all operations in WebSurge that are used for individual Url testing, or - as a group - for load testing. You can create Http requests that are made up of an Http Verb, a Url, Headers and Body Content (if any). Requests are created and can then be executed individually using one of the Run buttons for individual request testing and review.

The base request is represented in the WebSurge UI as the request editor and previewer in the right, main pane. It's the center of the UI as you spend most of your time creating, managing and testing individual requests, before eventually - if at all - running load tests.

Session

A session represents one or more Http requests as a group that can be executed as a set. You can execute this session of requests for load tests using the Start operation, or for one time execution in using Run All.

Sessions are represented in the WebSurge UI as the list of requests in the left panel.

Threads

Threads execute a number of simultaneous sessions that are executed in parallel when running a Load Test. Threads are associated with a fixed User and an Http Execution Context that manage state between requests in an individual Session.

Threads can be set in the Session Configuration or in the Toolbar Threads field.

User

A User associates an execution context with an executing session. All requests in a Session execute in the same context - one request after the other. When running a load test, each each Thread is assigned a User and Http Execution Context that can keep some state between requests. The thread then assigns a User to each Session as it's executed on the Thread. User state is explicitly created and applied by WebSurge as requests are processed, while Http Execution Context holds Http protocol state like Cookies and Credentials, Caching etc. that is applied and managed by the underlying Http client.

User settings can be configured via the User Configuration Form that allows you configure , specific user state settings that are used for any given session that is assigned to that user.

Http Execution Context

As requests are executed via Http there are Http state features like Cookies, Credential caching, resource caching that are applied. Each Thread during a load test, gets its own separate Http Execution Context that can - depending on settings - persist things like cookies, credentials etc. across many requests. In effect each Thread gets its own set of Http state features so each thread is independent of another.

Sessions, Threads and Users

In summary Requests, Sessions, Threads and Users are associated like this:

Sessions are made up of multiple requests
Many threads run many sessions simultaneously
Each thread maps to exactly one user
(but the same user can be uniquely duplicated on many threads)
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 a session and a 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.

Http Request State and Test Runs

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 requests, for that particular thread across any subsequent session runs.

Users

You can create custom users that allow overriding default request functionality either globally for all requests executed in that user context, or for a specific Url. You can override authorization headers and cookies globally, and headers and form data per specific urls.

If you don't need specific request overrides, there's no need to create custom users. WebSurge creates generic users for each request and if the exact request data is enough for request processing that is all that's needed. Only create custom users if you need to override request features.

Users can be created:

Generically
If you don't provide explicit users, WebSurge creates a generic user for each of the threads in the test.
Explicitly
You can explicitly create users via the User Configuration Form 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. Each user assigned to a thread always maintains its own individual user state - if the same user is assigned to multiple threads, each user's state is still separate. Typically it's sufficient to create a few users and let them be spread across even large numbers of threads in a load test.

Configuring Users and Session 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.