Wrk introduction

Before learning about wrk, my understanding of performance testing had been limited to ab (Apache Benchmark). I had the impression that the functionality of ab was relatively simple, that is, simply pressure testing a given API and then seeing how much concurrency was there. So I learned about it, and then I saw that other people were interested in wrk, so I recorded something about wrk in the meantime.

Functional overview

The basic function of wrk is actually very similar to ab, you can simply do some GET requests, and then calculate the QPS (Request Per Seconds) and RT (Response Time) and so on, but wrk can not directly perform POST requests (ab can). So, here’s a further important feature of wrk: it supports extensions via lua scripts, which allow you to

• execute a custom POST request
• call a login API first to get the authentication information and then give it to the next test API.
• test concurrency more comprehensively by setting up different APIs to test simultaneously.
• Wait for a while after calling an API before testing it (this API may be special)
• Customizing the presentation of test results

These are all extensions of the lua script, which will work much better than ab in this convenience. One interesting thing is that if you go to wrk, you will also find a wrk2 thing, it is actually a modified version of wrk, the author himself added a so-called constant throughput function, in fact, is not to test QPS, but to maintain a certain QPS, and then see how the server side of the response speed, how the performance, so In general, I don’t need wrk2.

Basic function demo

So I can only demonstrate a simple GET request here, which is to see how wrk performs these two simple operations. As for POST requests, I need to cover them in the next section Extended Features.

• A GET request

    [root@liqiang.io]# wrk -t1 -c2 -d5s http://google.com
    Running 5s test @ http://google.com
      1 threads and 2 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    17.33ms   17.71ms 150.59ms   94.35%
        Req/Sec   138.00     30.28   180.00     84.00%
      692 requests in 5.03s, 356.81KB read
    Requests/sec:    137.50
    Transfer/sec:     70.90KB

  I apologize for using google.com as a demo example here, but it does work, and it’s important to parse out what each of the input parameters means first:

  • -t1: means open a thread for testing
  • -c2: means open 2 concurrent tests
  • -d5s: means execute the test for 5s, from the result we can see that the execution time is actually 5.03 seconds, which means it is still controlled
  • url: this is the url to be tested

Extensions demo

lua script execution logic

Wrk’s POST requests cannot be executed directly via command-line arguments, so they need to be run by way of a lua script.

• In wrk, the lua contexts of each thread are independent and do not interfere with each other, which makes sense for writing lua scripts
• In wrk, lua scripts can be divided into three parts, and you can use only one of these phases for your custom scripts, or you can define them all, which are
  • setup: each thread is started and will only be executed once during its entire life cycle
  • start: when the test is executed, the lua thread will call its custom functions
  • stop: when the test is finished, the lua thread calls a function that is generally used to control the format of the output

lua scripting framework

After reading the theoretical part, let’s look at the lua framework that corresponds to each phase, i.e., how lua scripts should be written as specified by wrk.

Startup phase

Once the lua thread starts, it calls a custom function in this phase.

[root@liqiang.io]# cat setup.lua
local counter = 1
function setup(thread)
   thread:set("id", counter)
   table.insert(threads, thread)
   counter = counter + 1
end

As you can see, during the startup phase, you can modify the content of the setup function as a custom startup content, in which you can modify the thread-related information, such as modifying the thread’s variables, modifying the thread’s server address, etc. Generally, you don’t have to modify it, but if you want to, here are some parameters of the function for you to use: | function(variable) name | function(s)

Run phase

The run phase is the core of wrk. In this section, you can have multiple functions that can be defined, namely

Here is an example of how the code for each stage is written.

[root@liqiang.io]# cat running.lua
function init(args)
   requests  = 0
   responses = 0
   local msg = "thread %d created"
   print(msg:format(id))
end
function delay()
   return math.random(10, 50)
end
function request()
   requests = requests + 1
   return wrk.request()
end
function response(status, headers, body)
   responses = responses + 1
end

This is a simple example where each request is delayed by 10-50 milliseconds and the number of requests is recorded before the request is made and the number of responses to the request is recorded after the request is successful.

Ending phase

After the end, lua allows you to define your own processing results, where you can customize your output format, or if you don’t like the default output format, there is only one function that you need to define yourself: ```.

[root@liqiang.io]# cat stop.lua
function done(summary, latency, requests)
   for index, thread in ipairs(threads) do
      local id = thread:get("id")
      local requests = thread:get("requests")
      local responses = thread:get("responses")
      local msg = "thread %d made %d requests and got %d responses"
      print(msg:format(id, requests, responses))
   end
end

Special example

If you just want to modify the request and don’t want to customize anything else, then you can write the functions inside the request directly in lua, without returning and without writing the function definition, as in the following POST example.

POST request

If we follow the lua framework described in the previous section, we could define the request format in request() and just define the request as POST, but, as I mentioned at the end, wrk has taken into account the commonness of this scenario and simplified the feature so that you can just write a script without having to define function and return, for example, like this.

[root@liqiang.io]# cat post.lua
wrk.method = "POST"
wrk.body = "foo=bar&baz=quux"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"

This is an example of a POST, and then the lua script is loaded via wrk and run as follows

[root@liqiang.io]# wrk -c3 -d1s -t2 -s . /scripts/post.lua http://localhost:5000/api/v1/login

Others

lua helper functions

The Argument properties of done

done(summary, latency, requests) records a lot of data about the performance test, and contains the following fields.

A complex sample

[root@liqiang.io]# cat pipeline.lua
init = function(args)
   local r = {}
   r[1] = wrk.format(nil, "/?foo")
   r[2] = wrk.format(nil, "/?bar")
   r[3] = wrk.format(nil, "/?baz")
   req = table.concat(r)
end
request = function()
   return req
end