How to use the command 'wrk' (with examples)

The wrk command is a powerful HTTP benchmarking tool widely used for performance testing of web applications. It assists developers in evaluating various aspects of web servers, such as their concurrency, throughput, and latency under load. By simulating multiple requests in parallel over a designated period, wrk helps uncover potential bottlenecks, thereby enabling improvements in server performance. Key features of wrk include its usability in both single-threaded and multi-threaded modes and the capability to send multiple concurrent requests.

Use case 1: Run a benchmark for 30 seconds, using 12 threads, and keeping 400 HTTP connections open

Code:

wrk -t12 -c400 -d30s "http://127.0.0.1:8080/index.html"

Motivation:

This example is particularly useful for individuals who manage web servers and need to conduct stress tests to understand how their infrastructure handles simultaneous requests. By using this command, server administrators can assess the server’s behavior under heavy load, which can reveal performance limits and potential areas of improvement.

Explanation:

• -t12: This flag specifies that the test should be conducted using 12 threads. Each thread will independently create and manage multiple connections to the server, allowing a more efficient spread of the load across the server’s resources. By using multiple threads, you can simulate a real-world scenario where numerous users are accessing different resources of a web application simultaneously.

• -c400: This argument indicates that 400 concurrent HTTP connections should be maintained throughout the duration of the test. The high number of parallel connections helps verify whether the server can handle multiple simultaneous requests without significant performance degradation, simulating high-traffic conditions.

• -d30s: This option dictates that the benchmark shall run for a duration of 30 seconds. A substantial duration helps gather sufficient data points, providing a clearer picture of how the server performs over time under consistent load.

• "http://127.0.0.1:8080/index.html": This specifies the URL to which requests will be sent. The default IP address 127.0.0.1 indicates that wrk will test a locally hosted server. Adjusting the endpoint can help measure different parts of a web application to identify performance differences.

Example output:

Running 30s test @ http://127.0.0.1:8080/index.html
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.20ms  200.01us   4.75ms   85.34%
    Req/Sec    33.33k     1.11k   34.56k    95.10%
  11978520 requests in 30.00s, 11.13GB read
Requests/sec:  399228.00
Transfer/sec:    379.67MB

Use case 2: Run a benchmark with a custom header

Code:

wrk -t2 -c5 -d5s -H "Host: example.com" "http://example.com/index.html"

Motivation:

This use case is applicable when developers want to replicate specific HTTP request characteristics that include custom headers. Custom headers are often utilized to test particular server configurations, proxy settings, or simulate requests from different domains, making this a versatile tool for web developers and testers.

Explanation:

• -t2: Specifies that 2 threads should be used for the benchmark. While fewer threads mean less parallelism, it can still effectively simulate real user behavior for less intensive evaluations.

• -c5: Indicates that 5 concurrent HTTP connections will be maintained. This limited concurrency might be chosen for precision testing or to focus on analyzing the server’s responses for each individual request.

• -d5s: Denotes a shorter, 5-second test duration. Quick tests are handy for rapid iteration during development processes, allowing brief, frequent insights into performance changes.

• -H "Host: example.com": The -H flag sets a custom HTTP header. In this context, setting the Host header might be necessary when testing behind a load balancer or reverse proxy, which routes traffic based on the host value.

• "http://example.com/index.html": This points wrk to the URL to be tested. By using a different domain, developers can test the behavior of a deployed application as perceived by external users.

Example output:

Running 5s test @ http://example.com/index.html
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.01ms    0.89ms   13.12ms   75.65%
    Req/Sec     1.818k   110.22     2.01k    89.24%
  18080 requests in 5.00s, 16.21MB read
Requests/sec:   3616.00
Transfer/sec:      3.24MB

Use case 3: Run a benchmark with a request timeout of 2 seconds

Code:

wrk -t2 -c5 -d5s --timeout 2s "http://example.com/index.html"

Motivation:

Timeout settings are critical in networked applications to prevent stalled requests from blocking resources indefinitely. This example demonstrates how to set a specific timeout for requests, ensuring the server responds within a defined period, which is essential for applications requiring high availability or responsiveness.

Explanation:

• -t2: Specifies that 2 threads should be utilized. The number of threads determines how many requests are dispatched simultaneously, influencing the server’s load.

• -c5: Keeps 5 HTTP connections open. While fewer connections might mean a lighter load, it allows for evaluating performance in less congested conditions.

• -d5s: Dictates a 5-second duration for the entire benchmark. A reduced duration makes the command suitable for quick trials while developing or optimizing specific endpoints of an application.

• --timeout 2s: This flag sets a maximum wait time of 2 seconds for each request’s response. If a response takes longer, the connection is terminated. This ensures that underperforming servers do not indefinitely hold up concurrent resources, aiding in identifying lengthier delays.

• "http://example.com/index.html": Represents the URL target for the requests. Developers might choose this endpoint to test different content delivery times, analyzing latency and throughput variations.

Example output:

Running 5s test @ http://example.com/index.html
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.13ms    0.44ms    3.25ms   42.63%
    Req/Sec     2.11k     212.00      2.55k   85.75%
  21105 requests in 5.00s, 18.96MB read
Requests/sec:   4221.00
Transfer/sec:      3.79MB

Conclusion

The wrk command is invaluable for performance testing and benchmarking web servers. By simulating real-world conditions, such as multiple threads, connections, and custom headers, it provides key insights into a server’s ability to handle concurrent requests efficiently. Each example outlined above serves a distinct purpose, from stress testing infrastructure to ensuring rapid responsiveness in critical applications, highlighting wrk’s versatility and relevance in optimizing web server performance.