The key to achieving optimal MobiLink synchronization throughput is to have multiple synchronizations occurring simultaneously and executing efficiently. To enable multiple simultaneous synchronizations, MobiLink uses pools of worker threads for different tasks. One pool is dedicated to reading upload data from the network and unpacking it. Another pool of threads, called database worker threads, applies the upload to the consolidated database and fetches data to be downloaded from the consolidated database. Another pool of worker threads is dedicated to packing and sending the download data to the remote databases. Each database worker thread uses a single connection to the consolidated database for applying and fetching changes, using your synchronization scripts.

Contention

The most important factor is to avoid database contention in your synchronization scripts. Just as with any other multi-client use of a database, you want to minimize database contention when clients are simultaneously accessing a database. Database rows that must be modified by each synchronization can increase contention. For example, if your scripts increment a counter in a row, then updating that counter can be a bottleneck.

Synchronization requests are accepted (up to the limit specified by the -sm option) and the uploaded data is read and unpacked so that it is ready for a database worker thread. If there are more synchronizations than database worker threads, the excess are queued, waiting for a free database worker thread.

You can control the number of database worker threads and connections, but MobiLink always ensures that there is at least one connection per database worker thread. If there are more connections than database worker threads, the excess connections are idle. Excess connections may be useful with multiple script versions, as discussed below.

Number of database worker threads

Other than contention in your synchronization scripts, the most important factor for synchronization throughput is the number of database worker threads. The number of database worker threads controls how many synchronizations can proceed simultaneously in the consolidated database.

Testing is vital to determine the optimum number of database worker threads.

Increasing the number of database worker threads allows more overlapping synchronizations to access the consolidated database, as well as increased throughput, but it also increases resource and database contention between the overlapping synchronizations, and potentially increases the time for individual synchronizations. As the number of database worker threads is increased, the benefit of more simultaneous synchronizations becomes outweighed by the cost of longer individual synchronizations, and adding more worker threads decreases throughput. Experimentation is required to determine the optimal number of database worker threads for your situation, but the following may help to guide you.

For uploads, performance testing shows that the best throughput happens with a relatively small number of database worker threads: in most cases, three to ten worker threads. Variation depends on factors like the type of consolidated database, data volume, database schema, the complexity of the synchronization scripts, and the hardware used. The bottleneck is usually due to contention between database worker threads executing the SQL of your upload scripts at the same time in the consolidated database.

For downloads, when blocking download acknowledgement is used the optimum number of worker threads depends on the client-to-MobiLink bandwidth and the processing speed of clients. For slower clients, more worker threads are needed to get optimal download performance. This is because downloads involve more client processing and less consolidated database processing than uploads. When blocking download acknowledgement is used, database worker threads block until the remote database finishes applying the download. For non-blocking download acknowledgement, more workers are not needed.

When download acknowledgements are not used (the default), the client-to-MobiLink bandwidth is less influential because a database worker thread is free to process other synchronizations while other threads send the download. Thus the number of database worker threads is less critical.

Many downloads can be sent concurrently—far more than the number of database worker threads. For optimal download performance, it is important for the MobiLink server to have enough RAM to buffer these downloads. Otherwise the download is paged to disk and download performance may degrade. To specify the MobiLink server memory cache size, use the -cm option.

See -cm option.

If the MobiLink server starts paging to disk (possibly because of too many downloads being processed concurrently), consider using the -sm option to either decrease the number of database worker threads or limit the total number of synchronizations being actively processed.

See -sm option.

Leaving download acknowledgement off (the default) can reduce the optimal number of database worker threads for download, because database worker threads do not have to wait for clients to apply downloads.

See SendDownloadACK (sa) extended option.

If you use download acknowledgement, performance is better with non-blocking download acknowledgement (as opposed to blocking). In non-blocking acknowledgement mode the server reuses the worker thread while the remote database applies the download. This means that the number of worker threads may not need to be increased, which results in better performance.

To get both the best download throughput and the best upload throughput, MobiLink provides two options. You can specify a total number of database worker threads to optimize downloads. You can also limit the number that can simultaneously apply uploads to optimize upload throughput.

The -w option controls the total number of database worker threads. The default is five.

The -wu option limits the number of database worker threads that can simultaneously apply uploads to the consolidated database. By default, all database worker threads can apply uploads simultaneously, but that can cause severe contention in the consolidated database. The -wu option lets you reduce that contention while still having a larger number of database worker threads to optimize the fetching of download data. The -wu option only has an effect if the number is less than the total number of database worker threads.

See -w option and -wu option.

MobiLink database connections

MobiLink creates a database connection for each database worker thread. You can use the -cn option to specify that MobiLink create a larger pool of database connections, but any excess connections are idle unless MobiLink needs to close a connection or use a different script version.

There are two cases where MobiLink closes a database connection and open a new one. The first case is if an error occurs. The second case is if the client requests a synchronization script version, and none of the available connections have already used that synchronization version.

If you routinely use more than one script version, you can reduce the need for MobiLink to close and open connections by increasing the number of connections. You can eliminate the need completely if the number of connections used for synchronizations is the number of worker threads times the number of script versions.

An example of tuning MobiLink for two script versions is given in the following command line:

mlsrv11 -c "dsn=SQL Anywhere 11 Demo" -w 5 -cn 10

Since the maximum number of database connections used for synchronizations is the number of script versions times the number of worker threads, setting -cn to 10 ensures that database connections are not closed and opened excessively.

See -cn option.