Hi, Have you try to play with: http://docs.couchdb.org/en/1.6.1/config/http.html#httpd/server_options ? 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 <[email protected]> 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 > http://florin.myip.org/
