From dev-return-22225-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri May 11 15:32:40 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 E19A79D1C for ; Fri, 11 May 2012 15:32:39 +0000 (UTC) Received: (qmail 50788 invoked by uid 500); 11 May 2012 15:32:39 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 50733 invoked by uid 500); 11 May 2012 15:32:39 -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 50725 invoked by uid 99); 11 May 2012 15:32:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 15:32:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wickedgrey@gmail.com designates 74.125.82.42 as permitted sender) Received: from [74.125.82.42] (HELO mail-wg0-f42.google.com) (74.125.82.42) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 15:32:33 +0000 Received: by wgbds11 with SMTP id ds11so1596623wgb.5 for ; Fri, 11 May 2012 08:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=84MiZAJ/baX5QF45ahIRw+ZICQLgdxmMuOFp1F2etgE=; b=wxQSn/dqI1qkMLqUv8Au6rJglJt2YAr3yqfxTDSNdPeboijdbazWJa4MWJQWuPVHd5 9U/NBMBmYN5xoNhLB+qhicTlZvLAJs9qSkFhaKqwWZbc7doh58yA7VvkzZBuN05RtEo4 tcJ9nCAQVPYwV+LFcnTy6Jn9guOmPG8OjXcRkfrPc7Se/v9pR0Gu7t4h6UxzX0BBWBZX VyCavMBusLh9L15zlxR0ljV3MatJ0G8ZkOEsHuD9smp4kL+T+lGzfFORCyKaN1wFfG12 x0Ivdk4oBry1RkmH57U+SONKb7ofVwm0sq2V1Je50+0H8FM2QcTsiNOGDnDNcs/FNEko 0EEg== MIME-Version: 1.0 Received: by 10.180.99.72 with SMTP id eo8mr8787124wib.10.1336750331799; Fri, 11 May 2012 08:32:11 -0700 (PDT) Received: by 10.227.157.68 with HTTP; Fri, 11 May 2012 08:32:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 08:32:11 -0700 Message-ID: Subject: Re: Post-mortem From: "Eli Stevens (Gmail)" To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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. >From 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. 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). Eli