Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 31980 invoked from network); 12 Feb 2011 18:40:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Feb 2011 18:40:29 -0000 Received: (qmail 57847 invoked by uid 500); 12 Feb 2011 18:40:27 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 57742 invoked by uid 500); 12 Feb 2011 18:40:27 -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 57734 invoked by uid 99); 12 Feb 2011 18:40:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Feb 2011 18:40:26 +0000 X-ASF-Spam-Status: No, hits=3.6 required=5.0 tests=FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Feb 2011 18:40:22 +0000 Received: by yxd30 with SMTP id 30so1610198yxd.11 for ; Sat, 12 Feb 2011 10:40:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.96.2 with SMTP id y2mr2306809agl.140.1297535999571; Sat, 12 Feb 2011 10:39:59 -0800 (PST) Received: by 10.90.6.13 with HTTP; Sat, 12 Feb 2011 10:39:59 -0800 (PST) Date: Sat, 12 Feb 2011 15:39:59 -0300 Message-ID: Subject: Replication causes huge drop in performance From: Harry Vangberg To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a Couchdb 1.0.2 server running on an EC2 m1.xlarge (15GB / 4 cores) instance, with ~40m docs clocking in at ~45G. The database files are stored on EBS, configured as a 250G RAID-10 split on 4 EBS disks. I am trying to build a new slave instance on another EC2 instance. On the master I have max_http_pipeline_size=3D100 and max_http_sessions=3D1. When I start a pull replication from the slave instance, view requests to the master that usually have a ~1s response time, jumps to a ~30-40s response time, which breaks my app, that still relies on the master instance. It seems a bit aggressive. Any ideas? --=20 Harry Vangberg=A0 =A0 http://harry.vangberg.name