(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/
