couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Replication performance: pull vs. push
Date Thu, 03 Mar 2011 01:52:05 GMT
On Mar 2, 2011, at 6:54 PM, kowsik wrote:

> On Wed, Mar 2, 2011 at 1:29 PM, Filipe David Manana <> wrote:
>> On Wed, Mar 2, 2011 at 9:09 PM, kowsik <> wrote:
>>> My gut tells me the second case will be better for performance since
>>> the TCP connection (for the _changes feed) from A to B persists and
>>> the docs are sent one way without making a request (and hence less
>>> data transmitted per change). Is my hypothesis correct? I haven't yet
>>> looked at the packets to understand the differences between the two
>>> scenarios. But maybe someone else has already.
>> This scenario changes with the new replicator (in trunk only) which
>> adds more parallelism and the difference between pull and push
>> replications is much shorter now.
>> Recently Wayne Conrad tried out this new replicator and saw much
>> better performance/behaviour compared to the old one:
> Awesome! I have a follow up question on replication. I'm using couch
> as a message bus so have a lot of short-lived documents that come and
> go. Based on a previous thread, my understanding is that these
> documents are kept around in a deleted state forever for conflict
> resolution. If OTOH, I purge these documents, do the purge changes get
> propagated through replication?

Nope, purges are local and cannot replicate.

> Also is there a way in _all_docs to walk just the deleted documents so
> that I can purge them?

Hmm, not in _all_docs, but I imagine you could apply a filter for them to the _changes feed.

View raw message