Large files and streaming data become more and more typical on the Web. Broadcasting of TV and radio programs, live video news, large virtual machine images for downloading, videoconferencing, and many other services have become usual nowadays. For these websites’ owners, it is essential to ensure the servers support hundreds and thousands of viewers and visitors at a time. You can create load tests for such websites with LoadComplete.
Supported Protocols and Data Types
LoadComplete can record and simulate HTTP and HTTPS traffic. You can use it to create and run tests for websites and web applications that use any protocol built over HTTP or HTTPS. You will see the recorded and simulated messages as a sequence of HTTP requests and responses.
Create Load Tests for Streaming Data
You create a test for a website that provides large files or streaming data in the same way you create load tests for other websites:
-
You record user scenarios.
-
Configure request parameters, if needed.
-
Verify the scenarios.
-
Create load tests with virtual users that simulate the recorded scenarios.
You can find details in the Getting Started Tutorial topics of the Load Testing With LoadComplete section.
When creating and running such tests, it is helpful to know how LoadComplete handles large files and streaming data. See below.
How It Works
LoadComplete acts as a proxy between the client application (browser) and the tested web server. The proxy works transparently and does not cause pauses in data transfer. For example, if a server sends a large file, the proxy will not wait for the entire file to arrive to pass it to a client. It will transfer individual portions of data to the client while receiving them from the server.
LoadComplete does not cut the data that clients and servers send to each other. All large files and streaming data that clients and servers send to each other will reach the other side. However, when it saves data to the recorded scenario or test log, LoadComplete can cut response data to decrease the scenario and log size. Let’s see how it works during test recording and execution.
Recording Time
The recorder tracks the traffic and stores request and response data to the scenario you are recording:
-
For requests, the recorder stores –
-
The size of sent data.
-
The entire request content. If you upload a large file, the recorder will store the entire file to the recorded scenario. LoadComplete needs this to simulate real traffic later. So, if you simulate uploading large files, be ready that the size of your project will be huge.
-
-
For responses, the recorder saves –
-
The size of received data.
-
All or some part of response data, depending on the response size: to keep the size of recorded scenarios within reasonable bounds, the recorder saves no more than 50 MB of response data.
On the Recording toolbar, you can see the overall amount of the sent and received data:
In the Scenario editor, you will see the recorded traffic as a series of requests:
Example 1: Large file
Click the image to enlarge it.
Example 2: Streaming data
Click the image to enlarge it.
If response data was cut down to 50 MB, the scenario editor displays the following icon for that request. It means that actually, the response had more data that the recorder saved to the scenario. You can see the real size of response data in the right corner of the Response Body toolbar:
If you close the connection to the server while LoadComplete is recording a response with streaming data, the scenario editor will use the following icon to indicate the closed connection. On the Response Body panel toolbar, you can see the real size of response data, which was obtained before you closed the connection:
This case is typical when you are recording streaming video or audio responses. A distinctive feature of such responses is that they have no information on the content length, that is, they never “end”. Typically, you stop the transmission by closing the browser or page, which means you have closed the connection to the server.
-
Run Time
During scenario simulation, the runner needs to simulate the recorded traffic and to save information about requests and responses to the log.
When simulating large requests, the runner –
-
Sends the recorded traffic (for example, the entire large file) to the server.
-
Saves information on the request headers and bodies to the test log as the Store request and response data setting dictates (see below). If this setting permits saving the request body, then large files will be saved to the log, which will make the results huge. We suggest that you configure the setting value to decrease the log size.
When receiving large responses (large files or streaming contents), the runner –
-
Waits until the number of received bytes matches the number of bytes it recorded.
Do not confuse this number with the number of bytes stored for the response in your scenario. It is quite possible that the scenario stores only 50 MB of data, but the size of the recorded response is 100 or 200 MB. The runner will wait for the latter number.
-
If the Store request and response data setting permits saving response data to the test log, the runner will save the response data to the test log. If the response data exceeds 50 MB, the runner will save 50 MB only. However, for some tests, even this approach does not guarantee a small test log. We suggest that you configure LoadComplete settings to decrease the log size (see below).
Logging Large Requests and Responses
As we have said above, during the test run, LoadComplete saves the request and response data to the test log. If a test simulates lots of virtual users, or if it runs for a long time, the test log can be huge. You can use the Store request and response data setting of LoadComplete to decrease the amount of data saved. You can find it in the Tools > Options > Simulating > General dialog:
Click the image to enlarge it.
We recommend that you use either the Start line only or the Start line and headers option to prevent saving message bodies to the log. The third option – Complete data – means the runner will log the body data, which we would like to avoid. Although, in theory, large data can be included in message headers, in the real world, it is in message bodies.