insertBatchSize, changeLimitPerBatch and batchLimitPerRun methods

[navaneet]

Hi,

We are using sync-android version 1.1.5 and while trying to create a ReplicatorBuilder we came across the methods insertBatchSize, changeLimitPerBatch and batchLimitPerRun. Can you guys please explain how these methods affect performance and what these methods do in terms of improvements compared basic replication. The documentation regarding these methods were not adequate enough for us to understand their purpose and if bumping the numbers should have any side affects so any help in this regard will be much appreciated.

Replicator replicator = ReplicatorBuilder.pull().insertBatchSize(1000).changeLimitPerBatch(10000).
batchLimitPerRun(1000).to(dataStore).from(uri).filter(filter).addRequestInterceptors(bai).build();

Kind Regards Nav

[smithsz]

Hi @navaneet - Here's some more details regarding those methods:

• insertBatchSize - a bigger number will reduce the number of transaction operations on the device SQL database, but at the risk of repeating more work if a transaction is rolled back.
• batchLimitPerRun - removed in 2.x, the maximum number of batches to do before terminating the replication, reducing it allows a replication to be terminated early (i.e. without pulling all the changes).
• changeLimitPerBatch - a larger number will reduce the number of HTTP requests needed to pull the changes, but at an increased risk of the HTTP operation being interrupted by bad network or similar.

Hope this helps. Please get in touch if you have any further questions. Thanks.

[navaneet]

Hi,

Thanks for the detailed explanation. Is there any API with which we can limit the number of revisions that are downloaded during the first fetch of data. We have a large amount of documents and the replication is very slow on the android device hence are looking for ways to optimise the process. So, we were thinking if we could just fetch the latest revision only since it's the initial fetch and then on subsequent fetches we can replicate the changes from that point onwards, any other ideas to speed up the process?

By the way we are already using filtered replication.

[ricellis]

No, there is no other API besides the filter that will change the number of revisions replicated.

The replication will only download leaf revisions, so ensure your server-side conflicts have been resolved to reduce the number of full document revisions that need to be pulled to the device. Whilst the deleted leaf revisions still need to be downloaded these are usually small (containing only _id/_rev/_deleted metadata).

It may be worth contacting Cloudant support with your account details they could investigate the "shape" of your data WRT to conflicts etc.

[navaneet]

K thanks for the info