Because, when the specified script
duration runs out, or when the configured
stages ramp down or finish, current k6 versions abruptly terminate the currently running iterations and don’t emit more metrics from these VUs.
So, in your example, I suppose that ~458 VUs were currently somewhere after the
http.get() call in their iteration, but hadn’t finished it, probably busy sleeping. So, when the test ended, they had completed the HTTP request, but not the full iteration, causing you to have more
http_reqs metric values than
We have introduced a new feature in the most recent k6 code, currently available via the Docker
master image and slated to be released as k6 v0.27.0 next week. Now k6 has support for
gracefulRampDown, which would be 30s by default. These options will cause k6 to wait (up until the specified time) for any currently running iterations to finish when it has to ramp down or finish the test run, but it won’t start any new ones. In general, unless your iteration takes longer than
gracefulRampDown (and you can always set them to 0 to simulate the old behavior), in the new version
iterations should match
http_reqs in your example.