WebSocket Load Testing

Configuring a WebSocket Request

URL

To open a WebSocket connection, you are required to enter the WebSocket URL of the endpoint or IP address of the WebSocket URL you wish to check (the ws:// and encrypted wss:// protocols are supported). For example, wss://echo.websocket.org/

To turn on a more visually-friendly input mode, click the Detailed switch on the top of the section.

You can convert the URL to a dynamic value or context parameter here. For example, to dynamically change the target URL.

Send Data

If you need to transfer data to the target endpoint, in the Send Data field, specify a message in a string or binary format. Dotcom-Monitor will send the message to the target endpoint using the WebSocket protocol and wait for the response.

Dotcom-Monitor supports Razor expressions in the WebSocket messages. To send a string that contains a Razor expression, enter it in the Send Data field and use the Prepare Script to set the message type to Razor expression. Otherwise, the message will be parsed and sent as text. Use the following snippet in the Prepare Script field to notify the system that the message must be parsed with the Razor engine:

ProcessPostDataByRazor(currentTask);

In addition to the Razor engine, Dotcom-Monitor enables dynamically changing request body data by using data masks. To learn how to use the Razor syntax and data masks in sent data, and configure dynamically changing payload, see How to Dynamically Change Payload in HTTP Request.

Response Validation (Content Validation)

To validate a message string received from the WebSocket, you can assert keywords in the call execution scenario. The system will wait for the response from the target endpoint, and check the received message for the presence of the specified keyword in the string. If the keyword was not detected in the responses from the socket, an error will be generated.

In the Keyword fields, you can specify one word or phrase that you wish to search for in the response message. Use the plain text to specify a keyword:

Prepare Script and Post Script

The fields can contain C# code, which can be used for specific requests and URL data or for validating or publishing custom headers. Please see the Using Prepare Script and Post Script article or contact technical support for more details on usage.

The dynamic scenario of the WebSocket call execution can be specified in the Prepare Script field. The dynamic scenario can include a number of operations with binary or string data.

Binary formatted operations (msg as Base64 encoded):

• ValidateBinary(string msg) – checks if a WebSocket response is equal to specified binary data.
• ValidateBinaryContains(string msg) – checks if a WebSocket response contains specified binary data.
• SendBinary(string msg) – sends a binary message to a WebSocket.

Text formatted operations:

• SendText(string msg) – sends a text string to a WebSocket.
• ValidateText(string msg) – checks if a response from a WebSocket is equal to a specified string.
• ValidateTextContains(string msg) – checks if a WebSocket response contains a specified string.

In cases where any assertion was specified in the Prepare Script field, the system will wait for the specified assertion in the response and proceed with the script execution once the validation is successful. If a message with the specified assertion is not received, and the task completion timeout is reached, we will generate the validation error.

Dotcom-Monitor allows you to include as many operations as necessary in the Prepare script. However, if the task completion timeout is reached, the script execution will be terminated. The task completion time is counted from the start of the script execution.

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

SSL/Certificate Check

Secure Socket Layer SSL Certificate Check includes the following validation options:

• Authority: verifies whether a certificate chain contains a root certificate that is trusted, or not trusted.
• Common Name (CN): validates that an address you navigate to matches the address certificate the address was signed to.
• Date: verifies the certificate expiration date.
• Revocation: validates that the certificate’s chain of trust doesn’t contain a revoked certificate.
• Usage: verifies a certificate chain for the improper use of an intermediate certificate.
• Expiration Reminder in Days: a reminder that notifies (as an error) about certificate expiration.
• Client Certificate: client certificate name.

Time Validation Threshold (in seconds)

Enter the number of seconds the service should wait for a response from the web page before ending the request execution and returning an error. If this is left blank the default timeout for a request is 60 seconds.

Basic Authentication

The Basic Authentication scheme is used to allow users to access content on some websites. Once provided, login credentials will be passed along with the request header to the web server.

• Username: contains a username for HTTP/S basic or digest access authentication.
• User Password: contains a password for HTTP/S basic or digest access authentication.

Do not confuse Basic Authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Headers

The option enables adding any additional custom headers if it is necessary.

• Header Name: specify the name of the parameter as it will appear in the request.
• Value: enter the value associated with the name of the parameter.

DNS Options

The DNS Options feature allows users to choose how domain name server (DNS) requests are conducted during a monitoring task.

To specify the mode of resolving hostnames, in the DNS Resolve Mode section, select one of the available modes. For more details on the feature configuration, see DNS Mode Options.

The Custom DNS Hosts section allows to set up the mapping of IP addresses to hostnames. IPv6 and IPv4 DNS resolution is supported.

To specify the mapping, enter the IP address and the hostname in the corresponding fields.

See also: DNS Mode Options.

Error Filter

You can create filters that will ignore specific errors that you know may occur and are not relevant to the goal of a specific device. The system will not generate alerts on responses with error codes that match the filters. For example, DNS errors could be filtered out based on who is responsible for DNS server operations. .

In addition, you can configure the system to ignore a range of error codes using a dash, or multiple error codes using semicolons as a separator.

For example, if you do not care about 404 errors on one particular device, you can filter them out so that you do not receive alerts when they the errors are detected. The error details will be available for review in the device reports.