Shared Data Server

The shared data server (SDS) service provides a common data store that is accessible by virtual users (VUs). It provides a simple approach to solving numerous data handling problems that occur in performance testing.

It provides the following features:

Data can saved in a common data store by a VU and then read by other VUs within a test and between different test runs.
Data can be saved and retrieved as FIFO (first in, first out) and LIFO (last in, first out) lists via key lookup.
Data can be saved as single key=value pairs.
Virtual Users can optionally wait until the requested data becomes available.
Access is locked between VUs for atomic operations.
A snapshot of the data can be saved and restored.
Data lists can be read from CSV files or saved as CSV files.
The data persists between test runs.
You can manually amend the data from the user interface for interactive control of tests.
Scripts can be written within the tool to populate or manipulate the data.

Typical uses include:

Maintaining a list of values across test runs such as a list of account numbers to be processed, but where each account can only be processed once. During a test run each VU removes the next value from the list for processing.
Creating values by one group of VUs that must be processed by a different group of VUs. The VUs processing the values wait until a value appears if the list is empty.
Creating rendezvous points between VU and even between groups of users running on different injectors. For instance you can cause all users to log in then wait until a value is created in the shared data server before continuing. This value could be created following a condition such as 200 users having logged in.
Interactively controlling a running test. If your scripts take different paths depending on values read from the shared data server you can manually control tests. Scripts can wait on values or change pause times so you can change the number of active users or change transaction rates.
Saving information collected during a test in a convenient location for viewing or saving. An example is saving server error messages or other values during test runs. These can be viewed in the shared data server while the test is running then copied by cut-and-paste or saved to a CSV file.
Creating a synchronization lock that operates across all VUs in a test even if running on different injectors. If you have an action that only one VU can perform a time, you can create a lock that allows only single access.

This topic was last updated on August 19, 2021, at 03:30:52 PM.