Session Configuration Settings

Every session has a number of configuration settings that are associated with the session. These settings apply to all requests as they are run either individually or in a load test.

Settings are accessible via the Settings View which is accessed via the TabStrip on the very left of the screen using the icon. This brings up the Session Configuration view:

Many settings are available here most related around Http request processing and capturing of requests.

Http Settings might need to be Refreshed

Some Session settings affect the cached Http client that runs requests. The Http client for individual requests is re-used when running requests interactively in the UI, so in order to apply the new Http specific client settings you have to explicitly Reset the Session Http Settings via the icon on the toolbar. This operation clears cookies, cached values, proxy settings and completely resets the Http connection. Load Tests automatically reload all settings before a load test starts.

Settings

Note that each of the setting fields also displays detailed tool tip help by hovering over the input fields.

Site Base Url

This is a base Url that is applied against any partial Urls in the actual request list. A partial Url is something like /api/artists/1 and doesn't include all the required information to run the request - the domain and scheme are missing.

Site Base URl allows you to provide this base. Typical values look like https://albumviewer.west-wind.com/ or http://localhost:5001/.

Ignore Certificate Errors

If set ignores certificate errors and continues to run requests.

No Content Decompression

If checked the Http Response is not automatically decompressed from Gzip/Deflate/Brotly etc. By default all requests are decompressed to provide un-unencoded results.

Update Headers From Request Checkbox

If true this setting captures the actual request headers from the request that was run and provides them in the Request view. This adds headers that are generated, as well as headers that automatically are added by the Http client when requests are run.

If not set then the request only shows those headers that have been explicitly provided by the request in the Preview.

Request Delay Time

This sets the delay time between each request to simulate user interaction latency. The value is specified in Milliseconds. There are two special values:

0: There's no delay time, but the application yields
-1: There's no delay time and the application does not yield

The latter approach is highest performance approach, but be aware that it takes up considerably more CPU when running very high volume (in the 1000s of requests a second) tests.

Warmup Seconds

The number of seconds to let the test run before starting to collect test data. Warmup can be useful to avoid cold startup slow performance distortion in test results.

Request Timeout

The timeout after which a request is considered timed out and failed, in milliseconds.

Randomize Requests

If checked causes the requests in the Session to be randomly reordered before each session executes. This can produce more balanced test results especially on short tests which tend towards the first few requests in a sequence.

Note: If your requests depend on specific request order don't use this option.

Max Http Connections

This determines the maximum number of simultaneously open Http connections that can be active. Note that this is not the same as the number of threads/sessions as a single connection can potentially serve multiple requests.

Remove Start and End Percentile

This option allows to strip outliers from the result set by stripping a percentile from the both the start end of the result requests captured in a test.

It's an integer value that applied to the beginning and end. For example 5 means: 95th Percentile at the end and 5th Percentile at the beginning. For result stripping a small number - 1 or 2 is usually preferrable.

Replace Query String Value Pairs

This allows you replace a query key value - if found in a request - with a specific value. This can be useful for sites that use a querystring value to identify a user by id for example. Values are specified as replacement values using standard Query string syntax:

parm1=value1&parm2=value2

You can use Replace Cookie Value to replace the cookie header for all requests with a fixed cookie value. This is useful for sites that require complex authentication and allows you to capture a valid session cookie and apply it to all sessions.

Track Per Session Cookies

If true session cookies are tracked. So if you log into a site and receive a cookie that cookie is available in the next request.

Replace Authorization

You can use the Replace Authorization Value to replace the Authorization header on any request that has an Authorization header. This is useful for API requests that use Bearer tokens where you can capture a token from a login request (or browser based login) to capture the token and then apply it to all requests.

Note: An Authorization Header must exist on the request in order to replace it. If there's no Authorization header no replacement takes place.

Username and Password and Username/Password Type

You can specify a username and password and it can be applied using a type of Basic, Negotiate, Digest or Kerberos Authentication. Authentication is applied to all requests that request a 401 HTTP response. More info in the documentation.

Using username Authentication requires that you have a Site Base Url configured to the domain that the authentication.

User Agent

Optionally allows you to specify a Browser User Agent string for all requests.

Capture Minimal Response Data

When checked this doesn't capture successful Response output after the first 30,000 requests - only headers and request timings are captured after this initial result set. For long running, high volume tests this is recommended as it drastically reduces the size of the captured output.

Max Response Size

Lets you customize the max response size captured for requests. Again this is useful full long or super high volume tests to avoid huge request captures in memory.

Max Response size is not applied when running individual tests, only when running load tests.