Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9F62718358 for ; Fri, 9 Oct 2015 18:38:36 +0000 (UTC) Received: (qmail 45843 invoked by uid 500); 9 Oct 2015 18:38:35 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 45767 invoked by uid 500); 9 Oct 2015 18:38:35 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 45752 invoked by uid 99); 9 Oct 2015 18:38:35 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Oct 2015 18:38:35 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 99D9BC0BDA for ; Fri, 9 Oct 2015 18:38:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=6.31 tests=[RDNS_DYNAMIC=0.363, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id G7MVxVhYDvxO for ; Fri, 9 Oct 2015 18:38:28 +0000 (UTC) Received: from andrei.myip.org (75-149-39-41-SFBA.hfc.comcastbusiness.net [75.149.39.41]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id 4CF2242BE9 for ; Fri, 9 Oct 2015 18:38:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by andrei.myip.org (Postfix) with ESMTP id 5AA5DFA02AE for ; Fri, 9 Oct 2015 11:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: from andrei.myip.org ([127.0.0.1]) by localhost (weiqi.lan.home [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt2qsJCLXGxM for ; Fri, 9 Oct 2015 11:38:19 -0700 (PDT) Received: from andrei.myip.org (localhost [127.0.0.1]) by andrei.myip.org (Postfix) with ESMTP id 59EDCFA00DF for ; Fri, 9 Oct 2015 11:38:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 09 Oct 2015 11:38:19 -0700 From: Florin Andrei To: user@couchdb.apache.org Subject: Re: DB only replies to 1k HTTP connections Reply-To: user@couchdb.apache.org Mail-Reply-To: user@couchdb.apache.org In-Reply-To: References: <9ce10aa8b3c23e41fdd6e35dd8eb3373@andrei.myip.org> <5617730D.8030005@extravision.com> Message-ID: <97e957251f21cc076393b5b8cff55b58@andrei.myip.org> X-Sender: florin@andrei.myip.org User-Agent: Roundcube Webmail/0.9.2 (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/