以下方面均会影响到同步系统的吞吐量：

测试极其重要。在部署前，应使用您计划用于生产的硬件和网络来执行测试。还应该尝试以相同的远程数据库数量、相同的同步频率以及相同的数据量进行测试。MobiLink 重放工具可帮助进行这类测试。请参见MobiLink 重放实用程序 (mlreplay)。

此测试期间，您应该实验以下性能提示。

避免同步脚本中的争用和最大化同步脚本中的并发。

例如，假定 begin_download 脚本在表中添加一列，用以计算下载总数。如果多个用户同时执行同步，则此脚本可以高效地使他们的下载序列化。在 begin_synchronization、end_synchronization 或 prepare_for_download 脚本中使用相同的计数器将更加有效，因为这些脚本将在提交以前被调用，所以任何数据库锁只被保存极短的时间。更好的方法是只计数每个远程 ID 并通过稍后查询获得总数。

请参见争用。

有关同步的事务结构的信息，请参见同步过程中的事务。

使用 MobiLink -w 选项将 MobiLink 数据库工作线程数设置成提供最佳吞吐量的最小数目。您需要通过实验来确定适合您的情况的最佳数目。

较大数目的数据库工作线程可能通过允许同时有更多的同步来访问统一数据库来提高吞吐量，但随之而来的是可能增加争用和阻塞。

保持少量的数据库工作线程可以减小统一数据库中出现争用的可能性，减少到统一数据库的连接数，并减少优化高速缓存所需的内存。

在确认 -w 和 -wu 选项的最佳设置之前，不要在生产系统中设置这两个选项。

请参见：

• 数据库工作线程数
• -w mlsrv12 选项
• -wu mlsrv12 选项

较大的上载可导致统一数据库中较大的事务，而较大的事务会导致事务中容纳更多的锁定，从而增加阻塞和争用。这可能会对同步吞吐量和统一数据库的总体吞吐量有显著的不良影响。较小的上载可减少阻塞和争用，并且可能会显著提高吞吐量。

在带有 SQL Anywhere 远程数据库的 MobiLink 同步系统中，较小的上载可通过 dbmlsync 使用以下两种方式之一发送：

在服务器端，可通过使用 -tx 选项将大量事务从客户端一起批处理到一个统一数据库端事务来调整性能。一旦您设置客户端选项后，此选项非常方便，您只需调整 -tx 而无需更改客户端。请参见-tx mlsrv12 选项。

测试并调整这些客户端和服务器端选项以获得最大吞吐量。

在频繁同步而 BLOB 保持不变的行中包括 BLOB 会降低效率。要避免此类情况，可以创建一个包含 BLOB 和 BLOB ID 的表格，然后引用表中需要同步的 ID。

将 MobiLink 数据库连接的最大数目设置为同步脚本版本的数目与 MobiLink 数据库工作线程数的乘积加 1。这将减少需要 MobiLink 关闭和创建数据库连接的次数。使用 mlsrv12 -cn 选项设置连接的最大数目。

请参见MobiLink 数据库连接和-cn mlsrv12 选项。

确保运行 MobiLink 服务器的计算机具有足够的物理内存以满足高速缓存以及自身的其它内存需求。如果服务器需要超过 1.5 GB 的内存高速缓存，请考虑转用 64 位平台。

被积极处理的同步数量不受数据库工作线程数的限制。MobiLink 服务器可以同时为较大数量的同步解开上载并发送下载。一旦服务器开始分页到磁盘后，其吞吐量将显著下降，因此 MobiLink 服务器必须拥有足够大的内存高速缓存处理这些同步而无需分页到磁盘，这非常重要。在服务器日志中查找警告 10082，或从用于 MobiLink 的 SQL Anywhere 监控器中查找 "高速缓存已满" 警告以检测高速缓存何时不足。

MobiLink 服务器会根据需要自动增大或缩小其内存高速缓存。使用 -cmax、-cmin 和 -cinit 选项可控制 MobiLink 服务器的内存高速缓存。

• -cinit mlsrv12 选项
• -cmax mlsrv12 选项
• -cmin mlsrv12 选项

应该赋予 MobiLink 足够强的处理能力，以使 MobiLink 服务器处理不会成为瓶颈。通常，MobiLink 服务器所需的 CPU 远小于统一数据库所需的 CPU。但使用 Java 或 .NET 行处理增加了 MobiLink 服务器处理需求。实际上，网络限制或数据库争用更可能成为瓶颈。

统一数据库中脚本的性能是一个很重要的因素。在表中创建索引可以使上载游标脚本和下载游标脚本更有效地定位需要的行。但是，索引过多可能会减慢上载速度。

当使用 Sybase Central 中的 [创建同步模型向导] 来创建您的 MobiLink 应用程序时，在部署模型时会自动为每个下载游标定义一个索引。

使用与您的业务需求一致的详细程度最小的记录模式。缺省情况下，详细记录模式处于关闭状态而且 MobiLink 不将日志写入磁盘。您可以使用 -v 选项控制记录的详细程度，并使用 -o 或 -ot 选项将记录写入文件。

作为对详细日志文件的替代方法，您可以使用 MobiLink 监控器来监控同步。MobiLink 监控器不一定要和 MobiLink 服务器位于同一台计算机上，且监控器连接对 MobiLink 服务器的性能影响甚微。请参见MobiLink 监控器。

操作系统会限制服务器通过 TCP/IP 支持的并发连接的数量。如果达到此限制（超过 1000 个客户端同时尝试进行同步时，可能发生此种情况），操作系统可能会出现意外行为，如意外关闭连接及拒绝尝试连接的其它客户端。要阻止此行为，将操作系统配置为具有较高的 TCP/IP 连接限制并设置 -nc 选项，或使用 -sm 选项指定小于操作系统限制的最大远程连接数。

当客户端尝试与 MobiLink 服务器同步时，如果服务器已接受了由 -sm 选项指定最大数的并发同步，则此客户端会收到错误代码 -85 (SQLE_COMMUNICATIONS_ERROR)。客户端应用程序应该处理该错误并在几分钟后再次尝试连接。

请参见：

• -sm mlsrv12 选项
• -nc mlsrv12 选项
• 通信错误

目前尚未发现使用 Java 或 .NET 同步逻辑与 SQL 同步逻辑相比存在明显的吞吐量的差别。但 Java 和 .NET 同步逻辑对每个同步都会产生一些额外开销，需要占用更多内存。

另外，SQL 同步逻辑在运行统一数据库的计算机上执行，而 Java 或 .NET 同步逻辑在运行 MobiLink 服务器的计算机上执行。因此，如果统一数据库的负载很重，则可能非常适合使用 Java 或 .NET 同步逻辑。

使用直接行处理的同步增加了 MobiLink 服务器的处理负担，因此您可能需要更多的 RAM，也可能需要更多的磁盘空间和更强的 CPU 处理能力，这取决于实现直接行处理的方式。

如果您所具有的某些表需要比其它表更频繁地进行同步，则为它们单独创建发布和预订。在 Sybase Central 中使用同步模型时，可通过创建多个模型来完成上述操作。您可以比其它发布更频繁地同步此优先级发布，并且在非高峰时间同步其它发布。

注意仅下载需要的行，例如通过使用时间戳同步而不是快照同步。下载不必要的行是一种浪费，并会导致同步性能降低。

过度频繁的同步可能会在 MobiLink 同步系统中产生不必要的负担。请谨慎确定所需的同步频率。彻底测试以确保性能预期在生产环境范围内。

对于 SQL Anywhere 客户端，通过向 dbmlsync 提供估计的上载行数，可以显著提高上载大量行的速度。使用 dbmlsync -urc 选项执行此操作。

请参见-urc dbmlsync 选项。

从远程用户的角度来看，后台进行的同步越多，尽快完成同步的紧急性越低。考虑将您的远程应用程序设计为使用后台同步，以便远程用户即使在同步时也能够继续工作。