Earlier today, an EasySync user posted on the EasySync forum about an issue that they are running into. They are attempting to keep over 200,000 records in sync between their mobile device and their hosted database. They are experiencing poor performance when syncing, with the overall process taking well over 7 hours to complete.
The issue is most likely being caused by the large number of records involved, and in particular the impact this has when EasySync does a "Sync Check." So I thought I would take a few minutes to explain what the Sync Check phase is, and why it is both necessary and important.
When EasySync reaches its Sync Check phase, the UUIDs of all of the records (in all of the tables being synced) that are currently stored on the mobile device are gathered into a list and sent to the server. The server evaluates that list, checking each UUID to determine whether or not a particular record should still be on the mobile device.
How might a record be on the mobile device that shouldn't be there in the first place? It's possible that a record has been deleted by another user. Or perhaps the business rules have changed in such a way that a user previously had permission to access a record, but that permission has been revoked. For example, perhaps a customer account being reassigned to a different sales rep, a project or task that has been reassigned, and so on.
In any case, when the server has done its part of the Sync Check, it returns a list of the UUIDs that the mobile device should no longer store locally. The mobile device then goes through that list and deletes those records. This completes the sync process, ensuring that the mobile device is only storing the records that are applicable.
The Sync Check phase is an important, although admittedly inefficient part of EasySync's overall sync process. It's inefficient because, in order to remove records that should no longer be on the mobile device, EasySync has to move between layouts in an attempt to get context (meaning, a layout that is based on the table occurrence of a particular record) in order to delete. This is one of the many reasons that I've wanted to see support for SQL INSERTs, UPDATEs, and DELETEs added to FileMaker's ExecuteSQL calculation function. (With that added functionality, EasySync would be able to delete records without needing to "get context.")
When a large number of records are being synced, the inefficiencies of the Sync Check phase quickly become much more apparent. It decreases the speed with which EasySync on the mobile device can gather its list of UUIDs. It slows the server's role, because it has to evaluate a large number of UUIDs and determine if the mobile device should retain them. And it potentially puts burden back on the mobile device if a large number of UUIDs are found to be invalid.
In cases where such a large number of records are involved, you need to step back and think about what is being synced. It could very well be that you truly need mobile offline access to all of the records. If that's the case, EasySync might not be a good solution. However, if you do not need access to all of the records, and can instead work with just a subset of them, then you should consider syncing only those records instead. You will likely see much faster, and much more reliable performance from EasySync as a result.
If you are interested in FM EasySync, the award winning, open source sync framework for the FileMaker platform, please visit fmeasysync.com.