9,270
edits
Join the Power Platform Masterclass #2 starting April 23
Advanced sync setup: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
{{Synchronization TOC}} | {{Synchronization TOC}} | ||
This document explains how to speed up the [[synchronization]] of databases between server and mobile devices. | This document explains how to speed up the [[synchronization]] of databases between server and mobile devices. | ||
* We start by explaining internals of the synchronization process. | * We start by explaining the internals of the synchronization process. | ||
* Then we introduce main variables that control sync performance. | * Then we introduce main variables that control sync performance. | ||
* Finally, we'll explain how to formally write the setup string. | * Finally, we'll explain how to formally write the setup string. | ||
| Line 14: | Line 14: | ||
* It does not perform sync with SharePoint, OneDrive, Google Drive etc. | * It does not perform sync with SharePoint, OneDrive, Google Drive etc. | ||
For a typical configuration most of the sync time is spent in the SyncDownloader. | For a typical configuration, most of the sync time is spent in the SyncDownloader. | ||
== Measuring performance == | == Measuring performance == | ||
| Line 22: | Line 22: | ||
Let's start with a simple question: How can we measure the sync performance? | Let's start with a simple question: How can we measure the sync performance? | ||
First of all we shall compare FullSync times. (Incremental sync with its low data traffic and relatively large overhead is difficult to judge.) | First of all, we shall compare FullSync times. (Incremental sync with its low data traffic and a relatively large overhead is difficult to judge.) | ||
Secondly, we have two obvious metrics: | Secondly, we have two obvious metrics: | ||
* Total time spent in the download. You can find this number in the sync log and it looks like <code>"...<FullSync> Entitys=54141ms..."</code> (ms stands for milliseconds). This measure is good when we have relatively stable set of server data. However, it does not allow comparing sync performance against different servers. | * Total time spent in the download. You can find this number in the sync log and it looks like <code>"...<FullSync> Entitys=54141ms..."</code> (ms stands for milliseconds). This measure is good when we have a relatively stable set of server data. However, it does not allow comparing sync performance against different servers. | ||
* Alternative measure is the average time needed to download 1 record. Say we have this sync log excerpt: | * Alternative measure is the average time needed to download 1 record. Say we have this sync log excerpt: | ||
| Line 34: | Line 34: | ||
== How does SyncDownloader work == | == How does SyncDownloader work == | ||
Entities are somehow sorted. The exact criteria are not important. The downloader opens (usually) 3 download threads that work simultaneously - hence the term multi-downloader. Each thread takes first entity that was not yet downloaded and executes the download of all relevant entity records. When the download is ready, the downloader takes next free entity. If there is no such entity, the download thread quits. The downloader finishes when all its download threads terminate. | Entities are somehow sorted. The exact criteria are not important. The downloader opens (usually) 3 download threads that work simultaneously - hence the term multi-downloader. Each thread takes the first entity that was not yet downloaded and executes the download of all relevant entity records. When the download is ready, the downloader takes the next free entity. If there is no such entity, the download thread quits. The downloader finishes when all its download threads terminate. | ||
The download of entity records is done in steps, also denoted as pages. By default, one page consists of (up to) 500 records. For example, if we need to download 1253 account records, the downloader issues 3 web requests that return subsequently 500, 500 and 253 records. | The download of entity records is done in steps, also denoted as pages. By default, one page consists of (up to) 500 records. For example, if we need to download 1253 account records, the downloader issues 3 web requests that return subsequently 500, 500 and 253 records. | ||
| Line 41: | Line 41: | ||
The cache has limited space and it often happens that it gets filled. Here is a typical scenario: | The cache has limited space and it often happens that it gets filled. Here is a typical scenario: | ||
* 3 download threads download subsequently accounts, contacts and orders. | * 3 download threads download subsequently accounts, contacts, and orders. | ||
* SyncEngine processes the account entity. (The account entity is active.) | * SyncEngine processes the account entity. (The account entity is active.) | ||
* Hence the account records do not remain in the cache (they are immediately consumed), but contacts/orders are stored in the cache at least until accounts download finishes. | * Hence the account records do not remain in the cache (they are immediately consumed), but contacts/orders are stored in the cache at least until accounts download finishes. | ||