From wrk to k6: equivalent parameters and testing methodology

We are in the process of migrating our performance testing repository from utilizing wrk to k6. However, we aim to maintain the testing methodology employed in our previous setup.

In our current configuration, we handle large files containing approximately 300,000 requests. These requests are read line by line in our Lua script, and subsequently concatenated for utilization by the wrk tool. The command currently in use is as follows:

./wrk -d 1m -t 8 -c 256 --timeout 30s -R 16000 -q -s pipeline.lua http://localhost:8080 ./requests.reqs

Referencing the wrk documentation:

-c, --connections: total number of HTTP connections to keep open with
                   each thread handling N = connections/threads

-d, --duration:    duration of the test, e.g. 2s, 2m, 2h

-t, --threads:     total number of threads to use

-r:  throughput argument, total requests per second

My inquiry is regarding the equivalent parameters in k6. Can these be specified within the 'options' variable during k6 testing?

The concept of -c in wrk appears similar to the 'vus' concept in k6, but the documentation is somewhat ambiguous. The k6 documentation contains related options such as 'batch', 'rps', and 'iterations', but they don't exactly match the parameters in wrk.

I would greatly appreciate it if someone could provide an example of a complete test using k6 that mimic wrk methodology.

disclaimer: I know k6 is not focused achieving the highest concurrent users or RPS performance of tools like wrk.

Solution

I think the closest you can get with k6 is the following:

export const options = {
  scenarios: {
    wrk: {
      exector: 'constant-arrival-rate', // we want to control "RPS" (rate)
      rate: 16000, // "RPS" (executions of default function)
      duration: '1m', // run scenario for 1 minute
      preAllocatedVUs: 256, // start with 256 VUs (not really threads, but somewhat close)
      maxVUs: 2048, // maximum number of VUs, started on-demand to maintain the requested RPS (value guesstimated by threads*connections)
    }
  }
};

export default function() {
  http.get(...); // perform your request(s)
}

This will execute the default function 16000 times per second. If it only contains a single request, that equals 16000 rps. If your default function performs multiple requests, you have to account for that.

k6 will start VUs as required to match your target RPS. If you have 1000 VUs and request 10 RPS, the function will still be executed only 10 times per second and all other VUs will be idle.

Most of the options can either be specified via the exported options object or provided as commandline arguments. There is the --rps option, but its use is discouraged and you should prefer a scenario with a arrival-rate executor.

You might want to look into the noConnectionReuse option which controls whether connections are kept alive.