MobiLink Synchronization User's Guide
MobiLink Performance
Following are some suggestions to help you get the best performance out of MobiLink.
Test Before deploying, perform volume testing using the same hardware and network that you plan to use for production. Use this time to experiment with the following performance tips.
Avoid contention Avoid contention in your synchronization scripts. Another way of putting this is that you should maximize concurrency.
For example, suppose a begin_download script increments a column in a table to count the total number of downloads. If multiple users synchronize at the same time, this script would effectively serialize their downloads. The same counter would be better in the begin_synchronization or end_synchronization script because these scripts are called just before a commit.
For more information about contention, see Contention.
For information on the transaction structure of synchronization, see Transactions in the synchronization process.
Use an optimal number of worker threads Use the MobiLink -w option to set the number of MobiLink worker threads to the smallest number that gives you optimum throughput. You will need to experiment to find the best number for your situation.
A larger number of worker threads can improve throughput by allowing more synchronizations to occur at the same time.
Keeping the number of worker threads small reduces the chance of contention in the consolidated database, the number of connections to the consolidated database, and the memory required for optimal caching.
For example, in tests with fast clients, it was discovered that approximately five worker threads gave optimum throughput. For slower clients, more worker threads were needed to maximize download throughput, and the best upload throughput was obtained by limiting the number that can simultaneously upload, via the -wu option. In tests with extremely slow clients, the best throughput for both uploads and downloads was obtained with hundreds of worker threads with only five allowed to upload simultaneously. Note that these numbers are from a specific set of tests. Every deployment has different characteristics, and you must test to determine the optimal values for -w and -wu.
For more information about worker threads, see Number of worker threads.
For more information, see -w option and -wu option.
Enable the client-side download buffer for ASA clients For Adaptive Server Anywhere clients, a download buffer allows a MobiLink worker thread to transmit the download without waiting for the client to apply the download. The download buffer is enabled by default. However, the download buffer cannot be used if download acknowledgement is enabled (see next bullet).
For more information about setting the download buffer size, see the DownloadBufferSize (dbs) extended option.
Disable download acknowledgement for ASA clients Eliminating the optional download acknowledgement can free up MobiLink worker threads that are waiting for confirmation of successful download from the client, which also frees up the connection that the worker thread is using. It also makes it possible for MobiLink synchronization server to buffer the downloads.
You can also disable the download acknowledgement for UltraLite clients, but there is little performance improvement because UltraLite clients do not buffer downloads.
For more information about download acknowledgements, see the SendDownloadACK (sa) extended option.
Set the upload cache size To avoid the situation where the upload cache overflows to disk, set the upload cache size to be larger than the size of your largest upload stream times the number of worker threads. You set the upload cache size with the dbmlsrv9 -u option.
For more information, see -u option.
Set the download cache size To avoid the situation where the download buffer overflows to disk, set the download cache size to be larger than the size of your largest download times the number of worker threads. You set the download cache size with the dbmlsrv9 -d option.
For more information about setting the memory allocated to the download buffer, see -d option.
Set the BLOB cache size If your rows have data of type LONG VARCHAR or LONG BINARY, you can avoid having the BLOB cache access disk if you set the BLOB cache size to be larger than twice the largest BLOB data in a row times the number of worker threads. You set the BLOB cache size with the dbmlsrv9 -bc option.
For more information, see -bc option.
Set maximum number of database connections Set the maximum number of MobiLink database connections to be your typical number of synchronization script versions times the number of MobiLink worker threads, plus one. This reduces the need for MobiLink to close and create database connections. You set the maximum number of connections with the dbmlsrv9 -cn option.
For more information, see MobiLink database connections and -cn option.
Have sufficient physical memory Ensure that the computer running MobiLink has enough physical memory to accommodate the upload, download and BLOB caches in addition to its other memory requirements.
Use sufficient processing power Dedicate enough processing power to MobiLink so that the MobiLink server processing is not a bottleneck. In tests with an Adaptive Server Anywhere consolidated database, MobiLink required a third to a half of the processing required by Adaptive Server Anywhere when both were stressed and executing on the same computer.
Use minimum logging verbosity Use the minimum logging verbosity that is compatible with your business needs. By default, verbose logging is off, and MobiLink does not write its log to disk. You can control logging verbosity with the -v option, and enable logging to a file with the -o or -ot options.
As an alternative to verbose log files, you can monitor your synchronizations with the MobiLink Monitor. The Monitor does not need to be on the same computer as the MobiLink synchronization server, and a Monitor connection has negligible effect on MobiLink server performance. For more information, see MobiLink Monitor.
Java or .NET vs. SQL synchronization logic No significant throughput difference has been found between using Java or .NET synchronization logic vs. SQL synchronization logic. However, Java and .NET synchronization logic have some extra overhead per synchronization and require more memory.
In addition, SQL synchronization logic is executed on the computer that runs the consolidated database, while Java or .NET synchronization logic is executed on the computer that runs the MobiLink server. Thus, Java or .NET synchronization logic may be desirable if your consolidated database is heavily loaded.
Priority synchronization If you have some tables that you need to synchronize more frequently than others, create a separate publication and subscription for them. You can synchronize this priority publication more frequently than other publications, and synchronize other publications at off-peak times.
Download only the rows you need Take care to download only the rows that are required. It is easier to write synchronization scripts that download all rows upon each synchronization, but downloading unneeded rows affects synchronization performance.
Optimize script execution The performance of your scripts in the consolidated database is an important factor. It may help to create indexes on your tables so that the upload and download cursor scripts can efficiently locate the required rows. However, too many indexes may slow uploads.
For large uploads from ASA clients, estimate the number of rows You can significantly improve the speed of uploading a large number of rows by providing dbmlsync with an estimate of the number of rows that will be uploaded. You do this with the dbmlsync -urc option.
For more information, see -urc option.