First-class login scenarios

[dougbu]

As shown in https://github.com/wg/wrk/blob/7594a95186ebdfa7cb35477a8a811f84e2a31b62/scripts/auth.lua#L1-L18 the recommended login approach is for each thread to send a login request, copy the necessary information into the wrk table, then use that information in all subsequent requests. This has at least two downsides

• The initial request may have much higher cost e.g. latency than subsequent requests and can throw statistics off, especially in short runs.
• It requires a response() method and calling that method (even if it no-ops for requests after the first) is documented as expensive.

My suggestion is to add support for optional initial_request() and initial_response(status, headers, body) methods. If these are defined, call them immediately after init() (in each thread) for a single request then switch to the usual request() / wrk.request() and response(...) handlers. Reset all statistics after completing the first request. Also, delay the usual wrk.format() call 'til after initial_response(...) returns (removing the need for anything beyond wrk settings in initial_response(...).

[aprilahijriyan]

any news here?

[taihu]

This approach also could cause duplicated login requests. When one thread handles many connections, many requests could already be sent before the first response comes back. I ended up using a Node.js script to get the token and then pass it into wrk as an additional parameter.