incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torstein Krause Johansen <torsteinkrausew...@gmail.com>
Subject Re: Complex queries & results
Date Fri, 10 Jun 2011 05:03:50 GMT
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




Mime
View raw message