The following is a list of suggestions to help you get the best performance out of MobiLink.
The following all contribute to the throughput of your synchronization system: the type of device running your remote databases, the schema of remote databases, the data volume and synchronization frequency of your remotes, network characteristics (including for HTTP, proxies, web servers, and Redirectors), the hardware where the MobiLink server runs, your synchronization scripts, the concurrent volume of synchronizations, the type of consolidated database you use, the hardware where your consolidated database runs, and the schema of your consolidated database.
Testing is extremely important. Before deploying, you should perform testing using the same hardware and network that you plan to use for production. You should also try to test with the same number of remotes, the same frequency of synchronization, and the same data volume. During this testing you should experiment with the following performance tips.
Avoid contention and maximize concurrency in your synchronization scripts.
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, end_synchronization, or prepare_for_download scripts because these scripts are called just before a commit so any database locks are held for only a short time.
See Contention.
For information about the transaction structure of synchronization, see Transactions in the synchronization process.
Use the MobiLink -w option to set the number of MobiLink database worker threads to the smallest number that gives you optimum throughput. You need to experiment to find the best number for your situation.
A larger number of database worker threads can improve throughput by allowing more synchronizations to access the consolidated database at the same time.
Keeping the number of database 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.
See:
For SQL Anywhere clients, a download buffer allows a MobiLink database 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).
See DownloadBufferSize (dbs) extended option.
By default, download acknowledgement is not enabled. However, download acknowledgement can be useful for recording remote progress in the consolidated database. Blocking download acknowledgement ties up a database connection while the remote is applying the download. If you use download acknowledgement, you should use non-blocking download acknowledgement. Non-blocking download acknowledgement is the default.
See SendDownloadACK (sa) extended option and -nba option.
It is inefficient to include a BLOB in a row that is synchronized frequently. To avoid this, you can create a table that contains BLOBs and a BLOB ID, and reference the ID in the table that needs to be synchronized.
Set the maximum number of MobiLink database connections to be your number of synchronization script versions times the number of MobiLink database 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 mlsrv11 -cn option.
See MobiLink database connections and -cn option.
Ensure that the computer running the MobiLink server has enough physical memory to accommodate the cache in addition to its other memory requirements.
The number of synchronizations being actively processed is not limited by the number of database worker threads. The MobiLink server can unpack uploads and send downloads for a large number of synchronizations simultaneously. For best performance, it is very important that the MobiLink server has a large enough memory cache to process these synchronizations without paging to disk. Use the -cm option to set the memory cache for the MobiLink server.
See -cm option.
You should dedicate enough processing power to MobiLink so that the MobiLink server processing is not a bottleneck. Typically the MobiLink server requires significantly less CPU than the consolidated database. However, using Java or .NET row handling adds to the MobiLink server processing requirement. In practice, network limitations or database contention are more likely to be bottlenecks.
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 MobiLink Monitor does not need to be on the same computer as the MobiLink server, and a Monitor connection has a negligible effect on MobiLink server performance. See MobiLink Monitor.
Operating systems restrict the number of concurrent connections a server can support over TCP/IP. If this limit is reached, which may occur when over 1000 clients attempt to synchronize at the same time, the operating system may exhibit unexpected behavior, such as unexpectedly closing connections and rejecting additional clients that attempt to connect. To prevent this behavior, use the -sm option to specify a maximum number of remote connections that is less than the operating system limit.
When a client attempts to synchronize with a MobiLink server that has accepted its maximum number of concurrent synchronizations as specified by the -sm option, the client receives the error code -85 (SQLE_COMMUNICATIONS_ERROR). The client application should handle this error and try to connect again in a few minutes.
For more information about the -sm option, see -sm option.
For more information about SQLE_COMMUNICATIONS_ERROR, see Communication error.
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. So, Java or .NET synchronization logic may be desirable if your consolidated database is heavily loaded.
Synchronization using direct row handling imposes a heavier processing burden on the MobiLink server, so you may need more RAM, perhaps more disk space, and perhaps more CPU power, depending on how you implement direct row handling.
If you have some tables that you need to synchronize more frequently than others, create a separate publication and subscription for them. When using synchronization models in Sybase Central, you can do this by creating more than one model. You can synchronize this priority publication more frequently than other publications, and synchronize other publications at off-peak times.
Take care to download only the rows that are required, for example by using timestamp synchronization instead of snapshot. Downloading unneeded rows is wasteful and adversely affects synchronization performance.
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.
When you use the Create Synchronization Model Wizard in Sybase Central to create your MobiLink applications, an index is automatically defined for each download cursor when you deploy the model.
For SQL Anywhere clients, 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 are uploaded. You do this with the dbmlsync -urc option.
See -urc option.
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |