Hi Team,
we have noticed that a number of our user have reported CHT app getting slower as the number of records increased. In our context, most health facilities are offline and in a day one tablet can have more than 50 consultations. The tablets that have reported this issue have 2GB RAM 32GB ROM, storage consumption on these tablets is less than 50%.
Kindly guide me on how best I can streamline the app and also reduce the number of records replicated on the tablet.
Thanks,
Job
Do you have a count of about how many docs are on these tablets? (One way to see this is to check the About page in the app and see the value for “Number of Docs”.) Generally speaking, performance of the app will gradually decrease as the number of docs grows since it tries to do calculations over a larger and larger dataset.
Do you have any purging configured for your instance? Assuming the problem is caused by a large number of docs on the devices, then adding (or perhaps modifying) the purging configuration is going to be the most straight-forward way to mitigate this. The goal with purging is to identify the minimum set of data that is required on the device for the users to be able to effectively do their jobs and then set the purging config to keep only that data on the device. (Remember that purging will remove the docs from the device, but the all the docs will remain untouched on the server. No data is lost/deleted by CHT purging!)
Hey Josh,
Thanks for this.
One of the user has more than 10k records that are replicated on a device during log in.
We have not yet configured purging, I am curious to know how that can be done, considering the fact that most devices are offline and may be online at different times.
I would like to know how that can be configured without deleting docs from the client device.
Thanks,
Job
The purging docs have all the gory details, but to specifically answer your question, I can say that this functionality is designed for pretty much this exact situation!
Basically, the CHT purging functionality works by having the server periodically evaluate all the docs on the server against the set purge configuration to determine which docs should be considered “purged”. If a doc is found on the server that should be “purged”, it is not deleted or removed from the server (actually the doc is not modified at all). Instead a record is made in a separate purge database that designates that document (in the medic database) as “purged”.
Then, the next time the offline client syncs with the server, it will also sync the purge database. The client will then use the information in the purge database to determine if any of its existing docs (ones that were already synced to the server) should be removed (purged) from the device. New unsynced docs on the client will never be purged since the determination for which docs to purge is done by the server. So, there is no chance of data loss because data on the server remains untouched by the purging process and data on the client will not be purged unless it is already synced to the server. The key is to determine exactly what data needs to stay on the client device and set the purging config accordingly. If you purge too much from the client, then the users might not have the historical context they need to properly carry out their tasks. If you do not purge enough, then the large number of docs will slow down the device! (At 10k records, the CHT starts warning against even logging in as the user). Also note that purged documents will not be included in the initial sync to a client device if, for example, the user logs in on a new device.
This tread might be worth a read since it contains a lot of discussion of similar circumstances (though I don’t think the replication_depth configuration is applicable to your case since do to your flat hierarchy).
4 Likes