10,571
edits
Important: Deprecating old WebView — Publish failed error
Advanced sync setup: Difference between revisions
Jump to navigation
Jump to search
→Typical problems
(→Parameters that control the download process: MCRM 12.2 increased the limits: 10-4000 for Windows platforms, 10-1000 for mobile platforms.) |
|||
| Line 71: | Line 71: | ||
Before we discuss typical problems and try to formulate recommendations how to modify download parameters, let's explain how the client-server communication works. MCRM typically communicates over https. Here is a simplified web request life cycle: | Before we discuss typical problems and try to formulate recommendations how to modify download parameters, let's explain how the client-server communication works. MCRM typically communicates over https. Here is a simplified web request life cycle: | ||
* Request composition. (Done instantly, which means the time spent in this step is negligible with respect to other steps.) | * Request composition. (Done instantly, which means the time spent in this step is negligible with respect to other steps.) | ||
* Sending request to the server. The duration - called latency - depends upon the connection | * Sending request to the server. The duration - called latency - depends upon the connection bandwidth and the distance between the client and the server. | ||
* Server processing. This as a rule translates down to an SQL database query. Usually fast, but there are exceptions. Some queries may even timeout the server. | * Server processing. This as a rule translates down to an SQL database query. Usually fast, but there are exceptions. Some queries may even timeout the server. | ||
* Sending server response to the client. This also counts to the latency. | * Sending server response to the client. This also counts to the latency. | ||
| Line 78: | Line 78: | ||
=== Web latency === | === Web latency === | ||
Mobile networks are known for high latency. If you use VPN, latency gets larger. And if your server is 10000 km away, latency grows even more. Under these circumstances the whole web request life cycle may take well over 1 second. Theoretically, if the latency is 1.5 | Mobile networks are known for high latency. If you use a VPN, latency gets larger. And if your server is 10000 km away, latency grows even more. Under these circumstances, the whole web request life cycle may take well over 1 second. Theoretically, if the latency is 1.5 seconds and the 3 download threads run at the full speed (500 records per request), we get 1500 records in 1.5 seconds, i.e. 1 ms/record. However, this does not account for any overhead, for requests returning less than 500 records (they have the same latency!) and for download pauses. Hence, the real performance will be much smaller. | ||
Recommendations: | Recommendations: | ||
* Increase DownloadPageSize. Doubling the page size will halve the latency. | * Increase DownloadPageSize. Doubling the page size will halve the latency. | ||
: Risk: Higher memory consumption. | : Risk: Higher memory consumption. | ||
: Tip: You may use different page | : Tip: You may use different page sizes for different entities. If an entity has small records*), you can use a much higher page size. | ||
* Increase NumDownloadThreads. | * Increase NumDownloadThreads. | ||
<nowiki>*</nowiki>) "Small record" means record with small data. | <nowiki>*</nowiki>) "Small record" means record with small data. Records can be large either because of many nonempty columns (empty columns do not count) or because of large text column(s). Records containing a few hundreds of Bytes are considered small. Special case: Columns containing so-called attachments (activitymimeattachment.body, annotation.documentbody, salesliteratureitem.documentbody) are not counted. These columns use to contain big data and that's why they are excluded from SyncDownloader fetches. Instead, they are downloaded in a separate step as attachments. | ||
=== Dominant entity === | === Dominant entity === | ||
Imagine a model situation: 30 entities, 50000 contacts, remaining 29 entities have all together 50000 records as well. (This is what we call dominant entity.) How efficient is a multi-downloader in this situation? Let's do simple math: For | Imagine a model situation: 30 entities, 50000 contacts, remaining 29 entities have all together 50000 records as well. (This is what we call dominant entity.) How efficient is a multi-downloader in this situation? Let's do simple math: For simplicity, let the single thread download speed is 1000 records/second. | ||
* Single thread downloader needs 100 seconds. | * Single-thread downloader needs 100 seconds. | ||
* Multi-downloader (3 threads), contact entity is the last one: 67 seconds. (First 50000 records with the speed 3000 rec/sec, then 50000 records with the speed 1000 rec/sec.) | * Multi-downloader (3 threads), contact entity is the last one: 67 seconds. (First 50000 records with the speed 3000 rec/sec, then 50000 records with the speed 1000 rec/sec.) | ||
* Multi-downloader (3 threads), contact entity is the first one: 50 seconds. (Download of all non-contact records is "for free".) | * Multi-downloader (3 threads), contact entity is the first one: 50 seconds. (Download of all non-contact records is "for free".) | ||