下面列出了一些建议，可以帮助您从 MobiLink 获得最佳性能。
以下方面均会影响到同步系统的吞吐量：运行远程服务器的设备类型、远程数据库的模式、远程数据库的数据量和同步频率、网络特性（包括 HTTP、代理、Web 服务器和重定向器的特性）、运行 MobiLink 服务器的硬件、同步脚本、同步的并发量、使用的统一数据库的类型、运行统一数据库的硬件以及统一数据库的模式。
测试极其重要。在部署前，应使用您计划用于生产的硬件和网络来执行测试。还应该尝试以相同的远程数据库数量、相同的同步频率以及相同的数据量进行测试。此测试期间，您应该实验以下性能提示。
避免同步脚本中的争用和最大化同步脚本中的并发。
例如，假定 begin_download 脚本在表中添加一列，用以计算下载总数。如果多个用户同时执行同步，则此脚本可以高效地使他们的下载序列化。在 begin_synchronization、end_synchronization 或 prepare_for_download 脚本中使用相同的计数器将更加有效，因为这些脚本将在提交以前被调用，所以任何数据库锁只被保存极短的时间。
请参见争用。
有关同步的事务结构的信息，请参见同步过程中的事务。
使用 MobiLink -w 选项将 MobiLink 数据库工作线程数设置成提供最佳吞吐量的最小数目。您需要通过实验来确定适合您的情况的最佳数目。
较大数目的数据库工作线程可以通过允许同时有更多的同步来访问统一数据库，以提高吞吐量。
保持少量的数据库工作线程可以减小统一数据库中出现争用的可能性，减少到统一数据库的连接数，并减少优化高速缓存所需的内存。
请参见：
对于 SQL Anywhere 客户端，下载缓冲区使得 MobiLink 数据库工作线程不必等待客户端应用下载就可以传送下载。缺省情况下启用下载缓冲区。但是，如果启用下载确认，则不能使用下载缓冲区（见下一段）。
请参见DownloadBufferSize (dbs) 扩展选项。
缺省情况下，不启用下载确认。但是，下载确认对于在统一数据库中记录远程进度很有用。当远程应用下载时，阻塞下载确认会阻碍数据库连接。如果使用下载确认，您应使用非阻塞下载确认。非阻塞下载确认为缺省设置。
请参见SendDownloadACK (sa) 扩展选项和-nba 选项。
在频繁同步的行中包括 BLOB 会降低效率。要避免此类情况，可以创建一个包含 BLOB 和 BLOB ID 的表格，然后引用表中需要同步的 ID。
将 MobiLink 数据库连接的最大数目设置为同步脚本版本的数目与 MobiLink 数据库工作线程数的乘积加 1。这将减少需要 MobiLink 关闭和创建数据库连接的次数。使用 mlsrv11 -cn 选项设置连接的最大数目。
请参见MobiLink 数据库连接和-cn 选项。
确保运行 MobiLink 服务器的计算机具有足够的物理内存以满足高速缓存以及自身的其它内存需求。
被积极处理的同步数量不受数据库工作线程数的限制。MobiLink 服务器可以同时为较大数量的同步解开上载并发送下载。为得到最佳性能，重要一点是 MobiLink 服务器具有足够大的内存高速缓存来处理这些同步，而不分页到磁盘。-cm 选项用于设置 MobiLink 服务器的内存高速缓存。
请参见-cm 选项。
应该赋予 MobiLink 足够强的处理能力，以使 MobiLink 服务器处理不会成为瓶颈。通常，MobiLink 服务器所需的 CPU 远小于统一数据库所需的 CPU。但使用 Java 或 .NET 行处理增加了 MobiLink 服务器处理需求。实际上，网络限制或数据库争用更可能成为瓶颈。
使用与您的业务需求一致的详细程度最小的记录模式。缺省情况下，详细记录模式处于关闭状态而且 MobiLink 不将日志写入磁盘。您可以使用 -v 选项控制记录的详细程度，并使用 -o 或 -ot 选项将记录写入文件。
作为对详细日志文件的替代方法，您可以使用 MobiLink 监控器来监控同步。MobiLink 监控器不一定要和 MobiLink 服务器位于同一台计算机上，且监控器连接对 MobiLink 服务器的性能影响甚微。请参见MobiLink 监控器。
操作系统会限制服务器通过 TCP/IP 支持的并发连接的数量。如果达到此限制（超过 1000 个客户端同时尝试进行同步时，可能发生此种情况），操作系统可能会出现意外行为，如意外关闭连接及拒绝尝试连接的其它客户端。为防止此行为的发生，可使用 -sm 选项来指定低于操作系统限制的最大远程连接数。
当客户端尝试与 MobiLink 服务器同步时，如果服务器已接受了由 -sm 选项指定最大数的并发同步，则此客户端会收到错误代码 -85 (SQLE_COMMUNICATIONS_ERROR)。客户端应用程序应该处理该错误并在几分钟后再次尝试连接。
有关 -sm 选项的详细信息，请参见-sm 选项。
有关 SQLE_COMMUNICATIONS_ERROR 的详细信息，请参见通信错误。
目前尚未发现使用 Java 或 .NET 同步逻辑与 SQL 同步逻辑相比存在明显的吞吐量的差别。但 Java 和 .NET 同步逻辑对每个同步都会产生一些额外开销，需要占用更多内存。
另外，SQL 同步逻辑在运行统一数据库的计算机上执行，而 Java 或 .NET 同步逻辑在运行 MobiLink 服务器的计算机上执行。因此，如果统一数据库的负载很重，则可能非常适合使用 Java 或 .NET 同步逻辑。
使用直接行处理的同步增加了 MobiLink 服务器的处理负担，因此您可能需要更多的 RAM，也可能需要更多的磁盘空间和更强的 CPU 处理能力，这取决于实现直接行处理的方式。
如果您所具有的某些表需要比其它表更频繁地进行同步，则为它们单独创建发布和预订。在 Sybase Central 中使用同步模型时，可通过创建多个模型来完成上述操作。您可以比其它发布更频繁地同步此优先级发布，并且在非高峰时间同步其它发布。
注意仅下载需要的行，例如通过使用时间戳同步而不是快照同步。下载不需要的行是一种浪费，并会导致同步性能降低。
统一数据库中脚本的性能是一个很重要的因素。在表中创建索引可以使上载游标脚本和下载游标脚本更有效地定位需要的行。但是，索引过多可能会减慢上载速度。
当使用 Sybase Central 中的 [创建同步模型向导] 来创建您的 MobiLink 应用程序时，在部署模型时会自动为每个下载游标定义一个索引。
对于 SQL Anywhere 客户端，通过向 dbmlsync 提供估计的上载行数，可以显著提高上载大量行的速度。使用 dbmlsync -urc 选项执行此操作。
请参见-urc 选项。
| Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |