Can I run a load test against a vService or a Backend Service from TR7?

Short answer

Yes, with the two load generators in WEB-CLI. sys-cmd wrk sends requests with concurrent connections for the specified duration and, when the test finishes, writes the average request rate per second and the latency distribution as a single summary (sys-cmd wrk -t2 -c50 -d30s --latency <address>). sys-cmd h1load generates load to an HTTP/1 address and writes the values second by second. For a vService test, the address is the frontend IP and port of the vService; for a Backend Service test, it is the address of the server; when the Backend Service is tested directly, the route table of the Backend Service is first selected with sys-cmd route-table set. The load generator uses TR7's own processor and the tests send real requests; on a live target, the test is started with a low connection count and a short duration.

Problem: It Is Unknown How Much Load the Application Handles

Before a new vService is taken live, or after a Backend Service is added or a profile is changed, the aim is to measure how many requests per second are served and with what latency. A separate load test machine is not always ready; a quick measurement from the network where TR7 is located may be sufficient.

Solution: Two Methods

The two tools are alternatives to each other; they are not run against the same target at the same time.

Your situation	Suitable method
I want to see the total request rate and the latency percentiles at the end of the test; the target is HTTP or HTTPS	Method 1: sys-cmd wrk
I want to follow how the load is handled second by second and at which moment the latency increases; the target is HTTP/1	Method 2: sys-cmd h1load

Method 1: sys-cmd wrk Recommended

• How it workssys-cmd wrk sends requests from the selected route table to the target address for the -d duration with -c open connections; the connections are divided among -t threads. The results come as a single summary when the duration ends.
• Where it is openedWEB-CLI
• Requirement A user whose User Type is Admin.
• vService type HTTP; L7 TCP if the application behind it speaks HTTP

Step-by-Step Configuration

1

Adım 1 Select the route table

If the vService is to be tested, the route table through which its frontend IP is reached is selected; if the Backend Service is to be tested directly, the Route Table value of the Backend Service is selected; for the device itself, Host is written in the v-device field, and the route table name is taken from the Tab list:

sys-cmd route-table set v-device Host route-table <route-table>

2

Adım 2 Start with a short and light test

In the example, load is applied to the vService with the frontend IP 203.0.113.10 for 10 seconds with 2 threads and 50 connections:

sys-cmd wrk -t2 -c50 -d10s http://203.0.113.10/

Parameter	What it does
-t	Thread count; chosen so that it does not exceed the number of processor cores of the device
-c	Total number of open connections; cannot be smaller than the -t value
-d	Test duration, adjacent to the unit (10s, 1m)
--latency	Adds the latency percentiles to the end of the summary
-H	Adds a header to the request; a value with spaces is written in quotes
--timeout	The duration after which a request that gets no response is counted as a timeout

3

Adım 3 Test the HTTPS vService with the host name

If the vService serves multiple domain names, the Host header is added; the values are increased step by step:

sys-cmd wrk -t2 -c50 -d30s --latency -H "Host: www.example.com" https://203.0.113.10/

When the Backend Service is tested directly, the address is the address and port of the server (e.g. http://192.0.2.21:8080/); this test does not pass through the actions, cache and compression of the vService.

4

Adım 4 Keep the summary (optional)

The summary is written to a file; the download link is obtained with sys-cmd file show wrk-vip.txt (file show):

sys-cmd wrk -t2 -c50 -d30s --latency http://203.0.113.10/ | to-file wrk-vip.txt

Verification

1Test summaryTR7 side

The Requests/sec line in the summary shows the average request rate, and the Latency line shows the latency.

ExpectedNo Non-2xx or 3xx responses line

If a Non-2xx or 3xx responses line appears, some of the responses are errors or blocks; the measurement shows the behavior of the rules, not of the target.

2vService loadTR7 side

While the test is running, Live Stats is opened on the vService screen.

ExpectedThe HTTP Request/s card rises during the test

Method 2: sys-cmd h1load

• How it workssys-cmd h1load sends requests from the selected route table to an HTTP/1 address with -c concurrent connections and, during the test, writes the request count, the errors and the response times for each second line by line.
• Where it is openedWEB-CLI
• Requirement A user whose User Type is Admin.
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Select the route table

As in step 1 of Method 1, sys-cmd route-table set v-device Host route-table <route-table> is run.

2

Adım 2 Start the test

In the example, load is applied with 20 connections for 30 seconds; for a total request count instead of a duration, -n is used:

sys-cmd h1load -c 20 -d 30 http://203.0.113.10/

If no duration or request count is given, the test is stopped with Ctrl+C (frequently used parameters).

Verification

1Per-second linesTR7 side

In the lines written for each second, the request count, the errors and the response times are followed.

ExpectedError count zero, response times stable throughout the test

Common Mistakes

Load testing affects real users

The tests send real requests to the target. Applying load with high concurrency to a live vService can slow down users; the test is started with a low connection count and a short duration, and production targets are tested in a maintenance window (HTTP & Load Testing).

• Taking the result as the limit of the target. The load generator runs on TR7 itself and uses the processor of the device; at very high -t and -c values, the result shows the limit of the load generator, not of the target. For a real capacity measurement, the test is run from a separate client.
• Not taking the security rules into account. If WAF, Bot/DDoS or a connection limit is defined on the vService, the test traffic can be blocked or limited because it comes from a single source; in this case, the error count in the summary shows the behavior of the rules (What happens when the connection limit is reached?).
• Giving a -c value smaller than the -t value. Every thread uses at least one connection.
• Writing an address that contains & or $ without quotes. Addresses with a query string are written in single quotes ('http://203.0.113.10/?a=1&b=2'); | cannot be used inside a value (writing rules).
• Closing the WEB-CLI window while the test is running. When the connection closes, the command running in that session is terminated and the summary is not written.

How it is done in the documentation

• sys-cmd wrk · Frequently Used Parameters
• sys-cmd wrk · Things to Know
• sys-cmd h1load · Things to Know
• Live Stats · Frontend

Related questions

• The site is slow; how do I tell whether the problem is in TR7 or in the backend?
• The site became slow behind TR7; where should I start?
• What does the Live Stats screen show?
• What is the vService Limits profile; what are the default limits?