さまざまな要素が、同期システムのスループットに総合的な影響を及ぼします。例を次に示します。

テストは非常に重要です。配備する前に、運用環境で使用するのと同じハードウェアとネットワークを使用してテストを実行してください。また、リモートの数、同期頻度、データ量も同じにしてテストを実行します。このようなテストには、Mobile Link Replay Tool が役立ちます。 Mobile Link Replay ユーティリティ (mlreplay)を参照してください。

テストでは、以下のパフォーマンスのヒントを参考にしてください。

同期スクリプトでは、競合を回避し、同時実行性を最大化します。

たとえば、begin_download スクリプトが、テーブル内のカラムを増分してダウンロードの合計数をカウントするとします。複数のユーザが同時に同期を行う場合、このスクリプトによって効果的にダウンロードが直列化されます。begin_synchronization、end_synchronization、prepare_for_download の各スクリプトでも同じカウンタが有効です。これらのスクリプトはコミットの直前に呼び出され、データベースのロックは短時間ですむからです。リモート ID ごとにカウントし、後でクエリによって合計数を取得する方法をおすすめします。

競合を参照してください。

同期のトランザクション構造については、同期処理のトランザクションを参照してください。

Mobile Link サーバにより、ネットワークストリームを同時に処理する複数のネットワークワーカスレッドがサポートされます。複数のネットワークワーカスレッドが存在することで、特に暗号化や圧縮など、大規模な同期または小規模の多数の同期を伴う CPU 集約型ネットワークストリームオプションを使用しているときは、パフォーマンスが向上することがあります。システム内の各要求は、最大で 1 つのネットワークストリームスレッド上でアクティブにできます。

ストリームスレッドを設定するには、-wn mlsrv16 オプションを使用します。 -wn mlsrv16 オプションを参照してください。

Mobile Link データベースワーカスレッドでは、固定した数を指定するか、または Mobile Link サーバに自動的に調整させるようにするかを選択できます。-wm オプションを使用せず、固定数を使用する場合には、-w オプションにさまざまな値を実際に設定しながら、最適なスループットを達成できる最小の数を決定する必要があります。自動調整の場合は、-wm オプションでデータベースワーカスレッドの最大数を指定します。また、-w オプションは最小数となる初期値を指定するために使用します。-w オプションを使用しない場合は、デフォルトは 5 です。たとえば、-wm 50 を使用して、-w オプションを使用しない場合には、5 ～ 50 の範囲内で、Mobile Link サーバによってアクティブなデータベースワーカスレッドの数が定期的に調整されます。

データベースワーカスレッドの数が多いほど、統合データベースに同時にアクセスできる同期の数が多くなり、スループットが向上する「可能性があります」が、競合やブロッキングが発生する可能性が高くなります。

データベースワーカスレッドの数を小さい値にしておくと、統合データベースでの競合発生回数、統合データベースへの接続数、最適なキャッシュに必要なメモリを少なくすることができます。

• データベースワーカスレッド数
• データベースワーカスレッドの自動調整
• -wm mlsrv16 オプション
• -w mlsrv16 オプション
• -wu mlsrv16 オプション

Mobile Link サーバは、最大のスループットを実現できるように、負荷に基づいてデータベースワーカスレッドの数を自動調整できます。この自動調整を有効にするには、-w mlsrv16 オプションを使用して、同時に使用するデータベースワーカスレッド数の初期値を設定します。また、-wm mlsrv16 オプションを使用して、同時に使用するデータベースワーカスレッド数の最大値を設定します。Mobile Link サーバはシステムのパフォーマンスをモニタしながら、そのときの状況に応じて、-w および -wm　オプションで設定したパラメータの範囲内でデータベースワーカスレッドの数を増減することによって調整します。

統合データベースへのアップロードに同時に適用可能なデータベースワーカスレッドの最大数を指定する、-wu mlsrv16 オプションで設定した値は、自動的には調整されません。-wu オプションが指定されない場合は、任意またはすべてのデータベースワーカスレッドにアップロードが適用される可能性があります。適用されるデータベースワーカスレッドの数は変動します。Mobile Link サーバがスループットを高めようとしてデータベースワーカスレッドの数を増加させると、問題が検出されてスレッド数を減少させるまでの間、一時的に競合の発生が増加してしまう可能性があります。

サイズの大きいアップロードを実行すると、統合データベースにおけるトランザクションが大規模になる可能性があります。トランザクションが大規模になると、トランザクションで保持されるロックが多くなるため、ブロッキングと競合が増えます。これにより、同期スループットと統合データベース全体のスループットの両方が大幅に低下することがあります。アップロードのサイズを小さくすると、ブロッキングと競合が減り、スループットは大幅に向上する可能性があります。

SQL Anywhere リモートを使用した Mobile Link 同期システムでは、次のいずれかの方法で、dbmlsync からサイズの小さいアップロードを送信できます。

サーバ側では、-tx オプションを使用してクライアントの多数のトランザクションを 1 つの統合側のトランザクションにまとめることによって、パフォーマンスをチューニングできます。このオプションは、クライアント側のオプションを設定してある場合に、クライアントを変更しないで -tx をチューニングするだけで済むため、便利です。 -tx mlsrv16 オプションを参照してください。

スループットを最大化するために、これらのクライアント側とサーバ側のオプションをテストしてチューニングします。

BLOB が変更されていない場合、頻繁に同期されるローに BLOB を含めるのは非効率的です。これを避けるには、BLOB と BLOB ID を含むテーブルを作成し、このテーブル内で同期が必要な ID を参照します。

Mobile Link データベース接続の最大数を、同期スクリプトバージョンの数と Mobile Link データベースワーカスレッド数の積に 1 を加えた数に設定します。これにより、Mobile Link がデータベース接続を閉じたり作成したりする必要が少なくなります。接続の最大数は mlsrv16 -cn オプションで設定します。

Mobile Link データベース接続と-cn mlsrv16 オプションを参照してください。

Mobile Link サーバを実行しているコンピュータに、他のメモリ要件に加えて、キャッシュを確保する十分な物理メモリがあることを確認してください。サーバに 1.5 GB を超えるメモリキャッシュが必要な場合は、64 ビットプラットフォームへの移行を検討してください。

アクティブに処理される同期の数は、データベースワーカスレッドの数によって制限されません。Mobile Link サーバでは、多数の同期のアップロードのアンパックとダウンロードの送信を同時に行うことができます。サーバでディスクへのページングが開始されると、サーバのスループットは大幅に低下します。したがって、同期をディスクにページングしないで処理するために十分なメモリキャッシュが Mobile Link サーバにあることが重要です。キャッシュが小さすぎるかどうかを判断するために、サーバログに警告 10082 があるかどうか、または、Mobile Link 用 SQL Anywhere モニタに「キャッシュがいっぱいです」という警告があるかどうかを検索します。

Mobile Link サーバでは、必要に応じて、メモリを自動的に拡張または縮小します。Mobile Link サーバのメモリキャッシュを制御するには、-cmax、-cmin、-cinit オプションを使用します。

• -cinit mlsrv16 オプション
• -cmax mlsrv16 オプション
• -cmin mlsrv16 オプション

十分な処理能力を Mobile Link に確保して、Mobile Link サーバの処理がボトルネックにならないようにしてください。通常、Mobile Link サーバで必要とされる CPU 処理能力は、統合データベースの場合に比べて非常に小さくてすみます。ただし、Java または .NET のローハンドリングを使用する場合は、Mobile Link サーバの処理要件が増えます。実際には、ボトルネックの要因になることが多いのは、ネットワークの制限やデータベースの競合です。

統合データベースのスクリプトを実行するときのパフォーマンスは重要です。テーブルに対してインデックスを作成し、アップロードカーソルスクリプトとダウンロードカーソルスクリプトによって必要なローだけが効率的に特定されるようにすると便利です。ただし、インデックスが多すぎるとアップロードに時間がかかります。

Sybase Central で同期モデル作成ウィザードを使用して Mobile Link アプリケーションを作成する場合、モデルを展開すると、インデックスがダウンロードカーソルごとに自動的に定義されます。

ビジネスニーズに合う最小の冗長ロギングを使用してください。デフォルトでは、冗長ロギングは設定されておらず、Mobile Link はディスクにログを書き込みません。ロギングの冗長性を制御するには、-v オプションを使用します。また、-o オプションか -ot オプションを使用すると、ファイルへのロギングを有効にできます。

冗長ログファイルの代わりに、Mobile Link プロファイラで同期をモニタできます。Mobile Link プロファイラは Mobile Link サーバと同じコンピュータ上になくてもかまいません。また、モニタ接続が Mobile Link サーバのパフォーマンスに与える影響はほとんどありません。 Mobile Link プロファイラを参照してください。

TCP/IP を介してサーバがサポートできる同時接続数は、オペレーティングシステムによって制限されます。1000 を超えるクライアントが同時に同期しようとしたときにこの制限に達する可能性があります。この制限に達すると、オペレーティングシステムで予期しない動作が発生する可能性があります。たとえば、接続が予期せずに終了したり、接続しようとするクライアントが拒否されたりします。この動作を防ぐには、TCP/IP 接続の制限を引き上げるようにオペレーティングシステムを設定して -nc オプションを設定するか、-sm オプションを使用して、オペレーティングシステムの制限より少ない数をリモート接続の最大数として指定します。

クライアントは、-sm オプションで指定された同時同期の最大数をすでに受け入れている Mobile Link サーバと同期しようとすると、エラーコード -1305 (SQLE_MOBILINK_COMMUNICATIONS_ERROR) を受信します。クライアントアプリケーションはこのエラーを処理して、数分後に接続を再び試みます。

次の項を参照してください。

• -sm mlsrv16 オプション
• -nc mlsrv16 オプション
• 通信エラーが発生しました。

Java または .NET の同期論理と、SQL 同期論理では、スループットに著しい差は見られません。ただし、Java と .NET の同期論理では、同期ごとに余分なオーバヘッドが発生し、より多くのメモリが必要です。

さらに、SQL 同期論理は統合データベースが稼働しているコンピュータで実行されますが、Java または .NET の同期論理は Mobile Link サーバが稼働しているコンピュータで実行されます。このため、統合データベースの負荷が高い場合は、Java または .NET の同期論理が適していることがあります。

ダイレクトローハンドリングを使用して同期すると、Mobile Link サーバの負荷が高くなるので、ダイレクトローハンドリングの実装方法によっては、必要な RAM、ディスク容量、CPU 処理能力が増える可能性があります。

一部のテーブルを他のテーブルより高い頻度で同期する必要がある場合は、それらのテーブル用に別のパブリケーションとサブスクリプションを作成します。Sybase Central で同期モデルを使用する場合、これを行うには、複数のモデルを作成します。この優先パブリケーションを他のパブリケーションより頻繁に同期し、他のパブリケーションをピーク時以外の時間に同期できます。

スナップショットではなくタイムスタンプ同期を使用するなどして、必要なローだけをダウンロードするようにしてください。不必要なローのダウンロードは無駄であり、同期のパフォーマンスに悪影響を及ぼします。

同期の頻度が高すぎると、Mobile Link 同期システムに無用なな負荷がかかる場合があります。必要な同期の頻度は慎重に決定してください。徹底的にテストを実施して、期待するパフォーマンスが運用環境で達成されることを確認してください。

SQL Anywhere クライアントの場合、多数のローをアップロードするときは、アップロードするロー数の推定値を dbmlsync に指定すると、アップロード速度を大幅に改善できます。この操作には、dbmlsync -urc オプションを使用します。

-urc dbmlsync オプションを参照してください。

リモートユーザの観点では、バックグラウンドでの同期がより高い頻度で実行されると、同期をできるだけ速く実行する緊急性は低くなります。同期中もリモートユーザが作業を継続できるように、リモートアプリケーションでバックグラウンド同期が使用されるように設計することを検討してください。