It would be useful to me if the -t flag (Timeout in seconds) would accept decimal number, non-integer e.g. 1.5.
I looked at the code and it seems to me this change would be fully retro-compatible.
I use -t in load tests in combination with -c to control the request rate, even if the requests are long-running server-side and I just want to let them run, not caring about their results, and move on with new requests. E.g.
time hey -n 500 -c 2 -q 1 -t 1 "$URL"
For example when stress-testing a Cloud Run service, I can't send too many requests per second from a single client, otherwise I get some 429. I would benefit from a more fine-grained range of values for -t e.g. 1.5. Instead, my current workaround is to set a different (c,t) combination which results in an fraction that approximates the desired value.
Hi Jaana
It would be useful to me if the
-tflag (Timeout in seconds) would accept decimal number, non-integer e.g.1.5.I looked at the code and it seems to me this change would be fully retro-compatible.
I use
-tin load tests in combination with-cto control the request rate, even if the requests are long-running server-side and I just want to let them run, not caring about their results, and move on with new requests. E.g.For example when stress-testing a Cloud Run service, I can't send too many requests per second from a single client, otherwise I get some 429. I would benefit from a more fine-grained range of values for
-te.g.1.5. Instead, my current workaround is to set a different (c,t) combination which results in an fraction that approximates the desired value.Shall I give it a try and make a PR?