couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kowsik <>
Subject Re: _replicator vs. replicate
Date Wed, 26 Oct 2011 16:26:25 GMT
Just a quick follow up. Maybe you guys know this already, but thought
I'll share. I was exchanging tweets with @fdmanana about this issue
and he said this profound thing that made me smack my head.

"@pcapr @couchdb Likely. Push replications read from a local db, so no
connections used for that. And only 1 writer to write to remote db"

This was news to me. So we've switched over from using push
to pull replication and it's frickin fast! So all of the max_http_*
configuration for the replicator only applies to pull apparently. Now
the docs are getting replicated across east/west bi-directionally with
very low latency and I haven't seen the replicator give up after this

Like I said, learned something new. Wasn't obvious from the documentation.



ps: If your app is distributed like ours, you might find this

On Tue, Oct 25, 2011 at 8:46 AM, Max Ogden <> wrote:
> MIkeal's is easy to test: npm install replicate && replicate sourceurl
> destinationurl
> it's probably slower than the current stable release, but more reliable. the
> new replicator in trunk is apparently the most optimal solution, but it's
> not released in a stable version yet
> On Tue, Oct 25, 2011 at 10:57 AM, kowsik <> wrote:
>> Anyone done any benchmarking on @mikeal's replicate vs. the built-in
>> replicator? For, we have east/west continuous replication (on
>> AWS) and I'm frequently seeing slow-downs and replication stalls (even
>> during periods of inactivity). Restarting CouchDB will make it quickly
>> catch up and then things will get backed up again.
>> I like the convenience of having the built-in _replicator DB, but
>> sometimes it takes minutes for docs to get pushed across. We are
>> running 1.1.0 BTW.
>> Thanks,
>> K.
>> ---
>> @pcapr

View raw message