couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Vangberg <ha...@vangberg.name>
Subject Re: Replication causes huge drop in performance
Date Tue, 15 Feb 2011 12:39:44 GMT
Setting the session and pipeline size on the target did indeed help.
Still some performance drop, but a way more reasonable amount.

Thanks,

On 12 February 2011 19:10, Filipe David Manana <fdmanana@apache.org> wrote:
> On Sat, Feb 12, 2011 at 10:39 AM, Harry Vangberg <harry@vangberg.name> wrote:
>> 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=100 and
>> max_http_sessions=1. 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?
>
> If you want to decrease the number of http connections (and pipeline
> size) used by the pull replication triggered at the slave, you have to
> touch the max http sessions and pipeline size parameters in the slave,
> not in the master.
>
> Do you see this problem when you query with "?stale=ok" ?
> Also, how complex are your view's map and reduce functions?
>
>>
>> --
>> Harry Vangberg  <harry@vangberg.name>  http://harry.vangberg.name
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
>  Unreasonable men adapt the world to themselves.
>  That's why all progress depends on unreasonable men."
>



-- 
Harry Vangberg  <harry@vangberg.name>  http://harry.vangberg.name

Mime
View raw message