Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 45418 invoked from network); 5 Sep 2009 18:35:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Sep 2009 18:35:33 -0000 Received: (qmail 67065 invoked by uid 500); 5 Sep 2009 18:35:31 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 66982 invoked by uid 500); 5 Sep 2009 18:35:31 -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 66971 invoked by uid 99); 5 Sep 2009 18:35:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 18:35:31 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.212.171 as permitted sender) Received: from [209.85.212.171] (HELO mail-vw0-f171.google.com) (209.85.212.171) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 18:35:18 +0000 Received: by vws1 with SMTP id 1so1280699vws.13 for ; Sat, 05 Sep 2009 11:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=MhkbRQjSNWNpH+LetV+fWf2EO8dz8P2f9K+apImX6Ps=; b=GhrBgywtk1aIVEfkDaVvTBQhFQJFBHjxBxR52OdCBVZ+eqguMroFI5W7GBE5Rnr1gF zD5FDoNSkDaUytJr6IPQwQwV3eKqVp+1YebnOhrMqqYoX9QUM9Z/NPV3g6bebsx96mrC 83R9mywnZCkY3bUWSMNaQivUyn70eNZjMmgyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Mch3VRYYPffDBXAiu0vawzH3UkM+vfWIachZHSTfzEiUHkp/ROG+j1HXzXXJQabtP2 Uu7EtbqTpB7CcKekm9J9js8MZBgzhQWZvCwVECMKCeI01A4kDr+fJOIkfiWizQIByqDp OOiHl16cTV0l+hIdCdXHrcyAs8jcO5wWn+wbU= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.220.68.226 with SMTP id w34mr10507273vci.116.1252175696839; Sat, 05 Sep 2009 11:34:56 -0700 (PDT) In-Reply-To: <47F1032E-FA42-4A56-B1B7-B8C2FE8E5A9A@bzero.se> References: <47F1032E-FA42-4A56-B1B7-B8C2FE8E5A9A@bzero.se> Date: Sat, 5 Sep 2009 11:34:56 -0700 X-Google-Sender-Auth: 95ffcd917a129981 Message-ID: Subject: Re: comfy couch? From: Chris Anderson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Sep 2, 2009 at 11:33 PM, Martin Hedenfalk wrote: > Hello couchdb users, > > We're currently evaluating couchdb for a project and would very much > appreciate > any thoughts and insights regarding the suitability of couchdb for this. > > We want to use CouchDB on several nodes (say around 12 nodes initially, b= ut > may > grow over time). Each node runs our application that handles external > requests > by updating the local couchdb database. There is no loadbalancer. > Continuous replication between all nodes make sure all databases are > (eventually) consistent. The same document can be updated via different > nodes, > so conflicts are expected to happen. > > Any node can fail and should be synchronized when it is back online. > > We anticipate the system to handle around 1000 transactions per second. > While > load is not necessarily distributed evenly between all nodes, let's say > around > 100 tps per node. Everything you've said above, sounds like a sane deployment. 100 - 1000 tps per node should be possible on normal hardware. Remember that since you aren't partitioning (all nodes eventually see all updates) you won't get the pattern where each node gets only a portion of the write load. All writes are eventually performed everywhere. The multi-master configuration you describe will still absorb load spikes. Replication is a more efficient writer than most clients, so you should be able to load the cluster harder than a single node. > > What delay can we expect before a document is replicated to any of the ot= her > nodes? The couchdb book mentions a "complex algorithm determining the ide= al > moment to replicate". My initial tests (although with only two nodes the > same > network segment) indicates replication happens nearly instantly when > inserting > some hundred documents per second. > > Would a full mesh of continuous replication between many nodes pose a > problem? > So far I've only tested replication between two nodes. I'll add more node= s > to > the testbed as I get my hands on more machines. > > Is there any difference between push and pull mode replication? Pull replication is a little more efficient than push, due to http pipelining etc. > > There was however one troublesome issue with replication. There were 116 > documents missing in one database. Restarting both couches and trying any > combination of replication didn't help. One node was always running on 10= 0% > CPU > and the other machine was completely idle. Once I continued with the test > insertions and setting up continuous replication again it resolved itself= . > Have > anyone experienced the same thing? I'm not sure what could cause this - if you are able to make it reproducible, we can make sure it goes away. Chris > > I'm running CouchDB 0.10.0a810462 (I checked out the 0.10.x branch) on > FreeBSD > Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [hipe] [kernel-poll:false] > > thanks > =A0 =A0 =A0 =A0-martin > > > --=20 Chris Anderson http://jchrisa.net http://couch.io