couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: DB only replies to 1k HTTP connections
Date Sat, 17 Oct 2015 17:21:22 GMT

Have you try to play with:
Anything specific in network sysctl settings?

Also some script to reproduce the problem would be nice to see (:

On Fri, Oct 9, 2015 at 9:38 PM, Florin Andrei <> wrote:
> (replying to both Tom and Mike)
> I suspect it's not running into resource exhaustion of the usual kind (CPU,
> etc), but I don't have a clear proof.
> To begin with, it's hard to track CPU/disk/memory usage because the test is
> finished quickly; I am tracking _stats with Sensu and Graphite but I need to
> increase time resolution. Anyway, when I'm under the connection limit the
> system uses all CPU cycles and generates some decent disk usage but not too
> much. Userspace RAM is at less than 50%. The DB responds fairly quickly,
> within a dozen seconds for all requests, or so.
> Some ~1k requests in the pool (the first ones that issue a GET) work just
> fine.
> - node.js sends out "GET /db/_design/blah". CouchDB responds immediately
> with an empty ACK packet.
> - 7 seconds later there's a PSH/ACK from CouchDB containing the HTTP
> response headers (response headers to GET)
> - node.js responds with an ACK
> - CouchDB respons immediately with a PSH/ACK containing the JSON response
> (small JSON document)
> - immediately there's a FIN - FIN/ACK exchange both ways, closing the
> connection
> The connections that are too late to send a GET are like this:
> - node.js sends out "GET /db/_design/blah", and CouchDB responds with an
> empty ACK packet.
> - And then there's silence on that connection.
> - After 60 seconds, node.js times out its side of the channel by sending a
> FIN/ACK, to which the CouchDB instance responds with ACK.
> - After another 60 seconds of silence, I get another ACK packet from
> CouchDB, containing the HTTP headers of the response to the GET, but no
> data. The node.js instance goes "what is this? I've closed this channel
> already" and responds with a RST packet.
> The logic of the exchange is broken.
> It's interesting that there's a cut off after the winning ~1k connections in
> the "contest". If it was CPU exhaustion, I would expect a gradual buildup of
> failures.
> How many concurrent connections should I expect 1.6.1 to be able to handle?
> Surely there are people out there that are doing more than 1k concurrently.
> What's the cookbook recipe for that?
> --
> Florin Andrei

View raw message