From dev-return-22226-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri May 11 15:55:19 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7FB869DD9 for ; Fri, 11 May 2012 15:55:19 +0000 (UTC) Received: (qmail 24117 invoked by uid 500); 11 May 2012 15:55:18 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 24076 invoked by uid 500); 11 May 2012 15:55:18 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 24068 invoked by uid 99); 11 May 2012 15:55:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 15:55:18 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.54] (HELO mail-wg0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 15:55:11 +0000 Received: by wgbfg15 with SMTP id fg15so2490407wgb.23 for ; Fri, 11 May 2012 08:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mSnnvC6ZngDMuzksAyxW6y1fpKFRDFVJHT+wjSmpl+c=; b=CP1+Z40KegMlGcdxlwK4vQhAJ8TklIN61gHl5yV7YLuKQCzly6+W8lqiTW0F8Gy7Dz s0OrbUkFsjK3VG7ecWr+IUAMtg2Tev6H0x7wtqaRHrOU6Ve49JAnRWMixgluIOFREc2V coksMBumFFsVSNWLFqWSp1z6a7+vzo7RehJ9hbuB5v+qPymKTDOa5MZfe5UNjdIzMQSV 8B7mGK9MlMC0JE3WsXhrkQnmESf9q4czc4Z38/XeibnMInj4AHOrBfyUBJcQKTThqh1C SKCWm7ZZnqt6t9lZ4+0P6rjxb6s7976TX+RgWSRi6RoGozl+KwGb2QjmNUEuMokNNmxd /rAQ== Received: by 10.50.106.162 with SMTP id gv2mr2005393igb.40.1336751689684; Fri, 11 May 2012 08:54:49 -0700 (PDT) Received: from postel.westell.com (static-50-35-174-7.knwc.wa.frontiernet.net. [50.35.174.7]) by mx.google.com with ESMTPS id dk9sm3697032igb.13.2012.05.11.08.54.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 08:54:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Post-mortem From: Nathan Vander Wilt In-Reply-To: Date: Fri, 11 May 2012 08:54:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQns2Xgh+dcMsh70Yi1il2lm4wgKzH7c9osHV2Y06xIs2i6HrwwwsrPnF47L982Tyo0ldapV On May 11, 2012, at 8:32 AM, Eli Stevens (Gmail) wrote: > On Fri, May 11, 2012 at 7:57 AM, CGS wrote: >> What I don't understand is the followings: >> 1. Those guys wanted a single front-end server which should keep up = with >> the incoming requests, correct? As far as I understood, CouchDB = philosophy >> is based on safety of the data, which was implemented as direct = writes on >> harddisk. So, having only one front-end server on which you force its = hdd >> to to keep up with the high speed internet connection is just like = you want >> to force a river to flow only through a mouse hole. >=20 > =46rom my understanding of the post, the core issue wasn't a mismatch = in > scale between desired throughput (the river) and available throughput > (the mousehole), it was that under high enough load CouchDB stopped > honoring certain classes of requests entirely. That's not a "too > slow" problem, it's a "fell over and can't get up" problem. >=20 > I think it's very important that effort is made to reproduce and > address these issues, since without being able to put more definite > bounds on them, *everyone* is going to wonder if their load is high > enough to trigger the problems. Heck, I'm wondering it, and I don't > typically have more than a couple hundred docs per DB (but a lot of > DBs, and hundreds of megs of attachments per DB). Here's one with steps to reproduce, albeit requiring a public-facing = server capable of routing one special "I own this site" request to a = separate : https://issues.apache.org/jira/browse/COUCHDB-1429 That one found me within ten minutes of trying out http://blitz.io = (themselves a CouchDB user, IIRC) but it's just sat since I filed it. = Fortunately/unfortunately the site I could take down at about ~40 = concurrent requests gets about that many hits in a _month_, so I don't = need to switch to MySQL ;-) hth, -nvw=