[kiitos]

> I used plow to make concurrent HTTP requests and measure the results.

If this refers to https://github.com/six-ddc/plow then -- oops! lots of issues in that repo, no tests, etc. etc.

The results in the README are also pretty clearly unsound! In both scenarios, writes were faster than reads?

_edit_: I guess because the writes all returned 3xx, oops again!

Probably don't take this article's claims at face value...

[jacob2161]

(I didn't downvote you)

plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully.

The writes returned 3xx because the handler returns a redirect, so this is expected.

[kiitos]

> plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully.

HTTP load testing is a problem area that is much more subtle than it seems. I've no doubt that plow does what you're saying here, but, without any tests whatsoever, I have serious doubts that it does so correctly, particularly if/when the load test starts bumping up against any of the numerous bottlenecks that can affect results and their measurements.

> The writes returned 3xx because the handler returns a redirect, so this is expected.

Yeah, but, unless `plow` actually follows that redirect, it's not really measuring the actual end-to-end latency, and further the guestbook.cgi returns 301 See Other for both valid requests (that performed a write) and invalid requests (that didn't).

[jacob2161]

You have a fair point about plow. I've used it enough to know that it basically works at spamming HTTP requests at a specified concurrency. When I'm doing something where I want better accuracy I've tended to use K6 and Vegeta.

> Yeah, but, unless `plow` actually follows that redirect, it's not really measuring the actual end-to-end latency...

Not in this case, since the purpose here was to measure the POST (write) not the subsequent GET (read) that a browser would do after the redirect.