http_req_blocked should include delays caused by the --rps option

[na--]

If I have the following script:

import http from "k6/http";

export let options = {
    iterations: 200,
    vus: 50,
    rps: 10,
};

export default function () {
    http.get("https://test.loadimpact.com");
}

I'd currently get results at the end of the test like this:

http_req_blocked...........: avg=6.03ms   min=2.31µs   med=4.97µs  max=143.3ms p(90)=20.81ms  p(95)=23.95ms 
http_req_connecting........: avg=1.14ms   min=0s       med=0s      max=48.32ms p(90)=3.28ms   p(95)=3.52ms  
http_req_duration..........: avg=6.73ms   min=3.95ms   med=5.71ms  max=44.91ms p(90)=8.38ms   p(95)=12.56ms 
http_req_receiving.........: avg=942.68µs min=63.79µs  med=1.06ms  max=4.6ms   p(90)=1.49ms   p(95)=1.64ms  
http_req_sending...........: avg=113.91µs min=47.7µs   med=96.31µs max=875.1µs p(90)=179.04µs p(95)=211.77µs
http_req_tls_handshaking...: avg=4.45ms   min=0s       med=0s      max=68.94ms p(90)=16.49ms  p(95)=18.69ms 
http_req_waiting...........: avg=5.67ms   min=3.76ms   med=4.48ms  max=44.71ms p(90)=7.02ms   p(95)=10.85ms 
http_reqs..................: 200    10.04509/s
iteration_duration.........: avg=4.36s    min=151.15ms med=4.98s   max=5.03s   p(90)=5s       p(95)=5s      
iterations.................: 200    10.04509/s

There's absolutely no indication that the rps option has delayed or restricted any of the requests. And it has, tremendously, since without it, the summary looks like this:

http_req_blocked...........: avg=22.5ms   min=2.17µs  med=2.68µs  max=99.22ms  p(90)=91.12ms  p(95)=94.08ms 
http_req_connecting........: avg=3.77ms   min=0s      med=0s      max=20.42ms  p(90)=13.89ms  p(95)=19.88ms 
http_req_duration..........: avg=13.44ms  min=6.66ms  med=13.02ms max=23.39ms  p(90)=18.98ms  p(95)=20.79ms 
http_req_receiving.........: avg=410.97µs min=32.01µs med=71.82µs max=6.12ms   p(90)=719.63µs p(95)=2.45ms  
http_req_sending...........: avg=66.7µs   min=12.32µs med=31.63µs max=765.37µs p(90)=96.66µs  p(95)=215.62µs
http_req_tls_handshaking...: avg=17.58ms  min=0s      med=0s      max=79.89ms  p(90)=72ms     p(95)=74.32ms 
http_req_waiting...........: avg=12.96ms  min=6.59ms  med=12.76ms max=23.03ms  p(90)=18.69ms  p(95)=19.6ms  
http_reqs..................: 200    1288.038373/s
iteration_duration.........: avg=36.12ms  min=6.87ms  med=14.78ms max=117.1ms  p(90)=106.06ms p(95)=110.38ms
iterations.................: 200    1288.038373/s

I think we should record any delays caused by rps in the http_req_blocked metric. That metric isn't very usable at the moment anyway, and it makes sense to track the delay there.

[mstoykov]

I think this will be hard and instead, we should just deprecate the rps option with some link to how to use arrival rate.

[na--]

Hmm, it shouldn't be too hard, I think... But in any case, I don't think it will happen in 0.30, so I'll remove it from the milestone.

Looking over the issue again, calculating delays due to --rps might actually be the smaller half of the potential http_req_blocked usefulness. Delays in actually executing a request that is a part of http.batch() call that were caused by the batch and batchPerHost options seems even more useful. So, let's leave the issue open for now and consider its use cases again in the future.

[olegbespalov]

Team agreed that it should be addressed under a new HTTP module #2461