kProcessDelay

[mike]

I've been testing my app and noticed a ~ .5 second delay between the start of syncing (i.e. the value at kCompletedKeyPath changes) and the time TDPuller springs into action.  This delay appears to be due to kProcessDelay being set to 0.5 in TDReplicator.m.   I set it to a lower value and thus far have seen no ill effects.  Is it harmful to set it to a value lower than 0.5, like 0.05?

For reference here's some entries from my app's log with kProcessDelay set to .5 and -LogSync YES.  As you can see there's a .492 second delay between when my observer of kCompletedKeyPath fires (1) and when TDPuller starts its work (2).  I'm still looking into the delay between the (2) and (3).  I believe this is due to network and server latency.

(1) 13:31:57.762 MyApp[5768:907] SYNC progress: 1 of 2 

(2) 13:31:58.254| Sync: TDPuller[http://couchperf.infinitecampus.com:5984/channel-6bcf59eaf02fc145a8212134b56216ce] queued 1 remote revisions from seq=1903 (0 in bulk, 1 individually)

(3) 13:31:59.327| Sync: TDPuller[http://couchperf.infinitecampus.com:5984/channel-6bcf59eaf02fc145a8212134b56216ce] inserted 1 revs in 0.025 sec (39.9/sec)

(4) 13:31:59.333| Sync: ReplicatorManager: Updating {65B4191C-7DFA-448E-9030-D085300A5387 #2-7f1706dfcd307492be5bb4f2fb39a393} with {

    "_replication_id" = "23A0FBE6-90F1-4890-B13E-7029956E6465";

}

[Jens Alfke]

On Nov 13, 2012, at 12:44 PM, mike <lam...@gmail.com> wrote:

I've been testing my app and noticed a ~ .5 second delay between the start of syncing (i.e. the value at kCompletedKeyPath changes) and the time TDPuller springs into action.  This delay appears to be due to kProcessDelay being set to 0.5 in TDReplicator.m.  

kProcessDelay controls how often the replicator’s “inbox” is processed if it doesn’t fill up. For the puller, revision IDs are added to the inbox as they’re parsed from the _changes feed; and the inbox is processed by looking up all of the revision IDs in it to see if they’re already in the local database. The purpose of the inbox is to batch revisions together for efficiency. For example, the puller can check all the revisions in the inbox in one SQL query.

That said, the value of 0.5 sec was fairly arbitrary and may not be ideal. Especially in the case of the puller, revisions tend to come in from the _changes feed in big batches already, so adding an additional delay for batching may not make sense. 

However, that delay constant is also effectively inherited by TDPusher, where it’s used to batch multiple revisions into a single _revs_diff REST call; that batching is pretty important because it’s a remote call. So it might make sense to have a different delay for the puller and pusher, which implies something like a class method that returns the delay, instead of a constant in the base class.

—Jens