Multiple pull replication performance question

[Jordan Wood]

I am using two one-time filtered pulls in my iOS app in order to prioritize the fetching of data which is important for me to display to the user when I first sync to CouchDB.  Currently, I start them in the order of importance to the UI, but I'm letting them run concurrently.  The pull which gets the less important data has many more documents than the one which I really have to wait for in order to display parts of my UI.  How does Couchbase handle multiple concurrent pulls?  Am I correct in thinking that once the server has the response for my more critical data, It will get processed in a reasonable amount of time? (say, no more than a second later than if there were no other replications running)?  All of the data I'm talking about is comprised of very small documents with no attachments.  I'm using Cloudant to serve up the data.

My coworker will be adding this same prioritization scheme to the Android version of the app, is the advice the same for Android?

[Jens Alfke]

> On Apr 18, 2016, at 1:25 PM, Jordan Wood <wood.p...@gmail.com> wrote:
>
> How does Couchbase handle multiple concurrent pulls?

Each replication runs independently. On iOS they’re sharing a thread, but all the network processing is async. On other platforms each one has its own thread.

Mostly, the ordering depends on how the underlying HTTP stack behaves. The major bottleneck is that only a limited number of requests can be sent at a time, since HTTP/1 can only send one request at a time over a socket. On iOS I believe only 4 sockets are opened to a host, i.e. 4 simultaneous requests. These get shared between all replications with the same host, which can sometimes increase latency if you have several replications.*

It shouldn’t be a problem with only two replications, though, especially if you don’t have huge documents or attachments (which can tie up a socket for a long time.)

> Am I correct in thinking that once the server has the response for my more critical data, It will get processed in a reasonable amount of time? (say, no more than a second later than if there were no other replications running)?

Yes, it should be fine.

—Jens

* This is a lot better in the current master branch, where we’re now using NSURLSession, which gives us a separate socket pool for each replication. We’re also hoping to enable HTTP/2, which has better parallelism.