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.
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.
Note that each of the setting fields also displays detailed tool tip help by hovering over the input fields.
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
If set ignores certificate errors and continues to run requests.
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.
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.
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.
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.
The timeout after which a request is considered timed out and failed, in milliseconds.
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.
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.
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.
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:
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.
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.
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.
AuthorizationHeader must exist on the request in order to replace it. If there's no
Authorizationheader no replacement takes place.
You can specify a username and password and it can be applied using
Digest Authentication. Authentication is applied to all requests.
Optionally allows you to specify a Browser User Agent string for all requests.
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.
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.
Comment or report problem with topic