sys-cmd wrk

sys-cmd wrk sends requests with a large number of concurrent connections to an HTTP or HTTPS address from the route table selected in WEB-CLI for the specified duration; when the test finishes, it writes the average request rate per second, the amount of data transferred and the latency statistics as a single summary. It is used to measure how many requests a vService serves under a specific load.

Command Summary

TR7 WEB-CLI · sys-cmd wrk

# type wrk and press Tab: a free parameter

admin@TR7LBWAF01> sys-cmd wrk

<wrk-parameter-1>

 

admin@TR7LBWAF01> sys-cmd wrk -t<threads> -c<connections> -d<duration> <address>

admin@TR7LBWAF01>  

Everything written after the word wrk is passed to the tool as it is. There is no mandatory field; the address is written at the very end.

How It Works

Subject	Behavior
Context	The requests are sent from within the selected v-device and route table.
Duration	At the beginning of the test the target address, the duration, and the thread and connection counts are written; the results come as a single summary when the duration given with -d ends. If a duration is not given, the default duration of the tool is applied.
Stopping	Ctrl+C stops the test.
Pipe	The summary can be filtered with | or written to a file with to-file.
Recording	Every run is written to the user logs.

Frequently Used Parameters

Parameter	What it does	What is written after it
-t	Determines the thread count	A number, adjacent (e.g. -t2)
-c	Determines the total number of open connections; it is divided among the threads	A number, adjacent (e.g. -c50)
-d	Determines the duration of the test	A duration, adjacent to the unit (e.g. -d30s, -d1m)
--latency	Adds the latency percentiles to the end of the summary	—
-H	Adds a header to the request	"Header: value"
--timeout	Determines when a request that does not get a response is counted as a timeout	A duration (e.g. 5s)

The table summarizes the frequently used parameters; the full list depends on the version of the tool on the device.

Examples

TR7 WEB-CLI · A) A short and light test

admin@TR7LBWAF01> sys-cmd wrk -t2 -c50 -d10s http://10.0.7.20/

admin@TR7LBWAF01>  

TR7 WEB-CLI · B) 30 seconds with the latency percentiles

admin@TR7LBWAF01> sys-cmd wrk -t4 -c100 -d30s --latency http://10.0.7.20/

admin@TR7LBWAF01>  

TR7 WEB-CLI · C) An HTTPS vService with the host name

admin@TR7LBWAF01> sys-cmd wrk -t2 -c50 -d30s -H "Host: shop.example.com" https://10.0.7.20/

admin@TR7LBWAF01>  

TR7 WEB-CLI · D) Write the summary to a file

admin@TR7LBWAF01> sys-cmd wrk -t2 -c50 -d30s --latency http://10.0.7.20/ | to-file wrk-vip.txt

admin@TR7LBWAF01>  

Things to Know

The load affects real users

The test sends real requests to the target. On a live vService it is started with a low connection count and a short duration, and the values are increased step by step. WAF, rate limiting or connection limit rules can block the test traffic; the Non-2xx or 3xx responses line in the summary shows the number of such responses.

• The thread count. -t is chosen so that it does not exceed the number of processor cores of the device; more than that ties the measurement to the limit of the load generator instead of the target.
• The connection count cannot be smaller than the thread count. Every thread uses at least one connection.
• If the change second by second is to be followed, h1load is used.