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.

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, and may increase throughput. However, 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 database 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 can typically be achieved with three to ten database 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.

Use the -w mlsrv12 option to set the number of database worker threads. You can also use the -wm mlsrv12 option to let MobiLink server automatically adjust the number of database worker threads for the best throughput—assuming the number lies between the current -w and -wm settings. However, while -wm is convenient it may not work in all cases. As always, testing is vital to determine the optimum number of database worker threads.

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. So, 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 -cmax option.

See -cmax mlsrv12 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 mlsrv12 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 process download acknowledgement transactions.

See SendDownloadAck (sa) extended option.

For download acknowledgement, blocking download acknowledgement has been discontinued, so all download acknowledgement is handled as non-blocking, which has better performance. With non-blocking acknowledgement, the server reuses the database worker thread while the remote database applies the download. This means that the number of database 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 mlsrv12 option and -wu mlsrv12 option.

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 script 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 database worker threads times the number of script versions.

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

mlsrv12 -c "DSN=SQL Anywhere 12 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 database worker threads, setting -cn to 10 ensures that database connections are not closed and opened excessively.

See -cn mlsrv12 option.