If you're reaching for a tool like that and can code in Go, implementing a correct one is very easy (~200 loc): just spin up new goroutines for each request at a regular interval.
https://groups.google.com/forum/#!msg/mechanical-sympathy/ic...
How to avoid this error yourself? Don't make a pool of workers, have each 1000 requests be their own thread/goroutine. So you'll create 1000 goroutines per second, each of them doing their own request. This way you won't omit measurements by skipping beats.
In the case of wrk (the original wrk, not Gil Tene's version), you could use this version to check for maximum RPS / bandwidth. This is because it's sending requests as fast as it can, but one after the other.
In the case of wrk2, Gil Tene's version, you have to specify the rate at which to send requests. This is how it avoids coordinated omission.
However, I'm easily tempted by the new and shiny which led me to find another great HTTP benchmarking tool: https://github.com/tsenart/vegeta
Another tool I forgot to mention was wrk (and now wrk2) which are unique in that they are scriptable via lua.
The only services that I found to simulate real life usage were paying services, which is understandable. Maybe in the future with some bittorrent-like load testing framework, I don't know.
big step up over seige/AB imho
Also noteworthy is Tsung[0], which is (far) more complicated but can speak more protocols, be configured to emulate user behaviour a little more closely and send crazy amounts of traffic.
