Hi Robert, On 09/06/11 17:10, Robert Newson wrote:
If you're not keeping the connection alive (I assume a loop calling wget is unable to do so) then much of the variance will be down to creating new TCP connections. A further problem is that of ephemeral port exhaustion, you might find the spikes in latency are cyclical, which is when wget is blocked waiting for a port (the others still lingering in TIME_WAIT, for example).
Thanks for your concern, but I don't see this as a problem. I run these tests many times and remove the max/min responses that deviate from the main tendency. This I do for both loops of the wget. The test results are easily repeatable and I'm thus pretty confident to say that the query times go up <this> much on my system when Couch is busy updating its views.
I suggest using apachebench or nodeload (https://github.com/benschmaus/nodeload) with appropriate settings to reuse connections.
Thanks for that, I'll have a look at your pointers (have used ab -k before), nodeload is a new kid on the block I haven't checked out yet.
Normally, though, I'm satisfied with using httperf for testing read performance (making sure that I don't run out of file handles of course, as well as tuning the server side to re-cycle the TCP connections fast enough) and siege for testing write performance. I used wget here merely to get a quick indication of the difference in query times.
"I expect stale=update_after to behave the same as stale=ok but also trigger view index update." Yes, it's true.
Cheers for the confirmation. -Torstein
