Recommend max number of documents that tablets can handle

[rjcorwin]

No description provided.

[rjcorwin]

Using the new generate-cases command, I generated 1,000 fully filled out cases from one of our project on the server. This resulted in about 29,000 documents in the database.

The initial registration sync using the APK went fine. It took about 10 minutes for the documents to download. However, on subsequent sync with no activity on the client or server, the app is crashing with an OutOfMemoryError.

Here's the logcat, note the stack trace points to final nail in the coffin being a function in the sqlcipher library.

Subsequent tries to sync repeated this behavior.

Switching gears to the PWA, the initial "Registration Sync" took about 10 minutes however it, failed to indicate that it was done. The UI reported no error, just "in progress" and 29,000 docs written. There were errors reported in the logs, but these might not actually be errors, we're just reporting them as such and may be misinterpreting them.

Note that disk usage is looking pretty good on the PWA. A rough estimate is this model of Tablet could hold around 75,000 cases.

Alas, on the subsequent sync after navigating away from the "stuck" sync. The sync seemed to start over at sequence 0. Only about half a megabyte is transferred, but it's a lot of requests to compare revisions from sequence 0 and so that took about 10 minutes.

Lastly, on the "third sync", or rather the "second standard sync that is not registration sync", it picked up at the last sequence and took only moments to sync.

Perhaps the APK is crashing because it's starting a sync from sequence 0 of a large local database? Perhaps it's not starting at sequence 0 on subsequent sync, that could be unique to the PWA because the PWA seemed to have some error at the end of the registration sync, which could be the underlying reason the subsequent sync went back to 0.

More testing to be done!

[rjcorwin]

When the APK does the subsequent sync, it appears to pick back up at the last sequence. I'm assuming this is because it made it to the complete callback on it's registration sync.

Trying to trigger the app crash is possible when doing a VERY large request to changes log. 1,000 limit is fine, 9,000 pushes it over the edge. Note how the last one does not return.

[rjcorwin]

Doing a large allDocs can crash it as well.

[rjcorwin]

Good news! Setting the since parameter to define a sequence since to sync with avoids crashes. It thought at first maybe it was because I was picking sequences that were not very far back in time but going all the way to the beginning (this db starts at sequence 64 for some reason), it still works.

[rjcorwin]

Uh oh, now regular sync is working on this tablet. Something about my test runs must have unblocked what was causing this issue. Perhaps my slow onramp of the sequence IDs during sync? I'll have to reinstall and test again. Moving this work over to "Fix crashing tablet on sync with APK in group with 1,000s of records #1995".