次に、Mobile Link の最高のパフォーマンスを引き出すために推奨される事項のリストを示します。
同期システムのスループットに総合的に影響を与える要素には、さまざまなものがあります。それは、リモート・データベースを実行するデバイスのタイプ、リモート・データベースのスキーマ、リモートのデータ量と同期頻度、ネットワーク特性 (HTTP、プロキシ、Web サーバ、リダイレクタなどの特性)、Mobile Link サーバを実行するハードウェア、同期スクリプト、同時に同期するデータ量、使用する統合データベースのタイプ、統合データベースを実行するハードウェア、統合データベースのスキーマです。
テストは非常に重要です。配備する前に、運用環境で使用するのと同じハードウェアとネットワークを使用してテストを実行してください。また、リモートの数、同期頻度、データ量も同じにしてテストを実行します。テストでは、以下のパフォーマンスのヒントを参考にしてください。
同期スクリプトでは、競合を回避し、同時実行性を最大化します。
たとえば、begin_download スクリプトが、テーブル内のカラムを増分してダウンロードの合計数をカウントするとします。複数のユーザが同時に同期を行う場合、このスクリプトによって効果的にダウンロードが直列化されます。begin_synchronization、end_synchronization、prepare_for_download の各スクリプトでも同じカウンタが有効です。これらのスクリプトはコミットの直前に呼び出され、データベースのロックは短時間ですむからです。
競合を参照してください。
同期のトランザクション構造については、同期処理のトランザクションを参照してください。
Mobile Link の -w オプションを使用して、Mobile Link データベース・ワーカ・スレッド数を、最適なスループットが得られる最小値に設定します。使用状況に合った最適な数を見つけるには、実験が必要です。
データベース・ワーカ・スレッドの数が多いほど、統合データベースに同時にアクセスできる同期の数が多くなり、スループットが向上します。
データベース・ワーカ・スレッドの数を小さい値にしておくと、統合データベースでの競合発生回数、統合データベースへの接続数、最適なキャッシュに必要なメモリを少なくすることができます。
次の項を参照してください。
SQL Anywhere クライアントの場合、ダウンロード・バッファにより、クライアントがダウンロードを適用するのを待たずに、Mobile Link データベース・ワーカ・スレッドがダウンロードを転送できます。ダウンロード・バッファはデフォルトで有効になっています。ただし、ダウンロード確認が有効になっている場合は、ダウンロード・バッファを使用できません (次の項目を参照)。
DownloadBufferSize (dbs) 拡張オプションを参照してください。
デフォルトでは、ダウンロード確認は無効になっています。ただし、ダウンロード確認は、統合データベースでリモート・プログレスを記録するときに便利です。ブロッキング・ダウンロード確認は、リモートがダウンロードを適用しているときにデータベース接続を占有します。ダウンロード確認を使用する場合は、非ブロッキング・ダウンロード確認を使用してください。非ブロッキング・ダウンロード確認がデフォルトです。
SendDownloadACK (sa) 拡張オプションと-nba オプションを参照してください。
頻繁に同期されるローに BLOB を含めるのは非効率的です。これを避けるには、BLOB と BLOB ID を含むテーブルを作成し、このテーブル内で同期が必要な ID を参照します。
Mobile Link データベース接続の最大数を、同期スクリプト・バージョンの数と Mobile Link データベース・ワーカ・スレッド数の積に 1 を加えた数に設定します。これにより、Mobile Link がデータベース接続を閉じたり作成したりする必要が少なくなります。接続の最大数は mlsrv11 -cn オプションで設定します。
Mobile Link データベース接続と-cn オプションを参照してください。
Mobile Link サーバを実行しているコンピュータに、他のメモリ要件に加えて、キャッシュを確保する十分な物理メモリがあることを確認してください。
アクティブに処理される同期の数は、データベース・ワーカ・スレッドの数によって制限されません。Mobile Link サーバでは、多数の同期のアップロードのアンパックとダウンロードの送信を同時に行うことができます。最高のパフォーマンスを得るには、同期をディスクにページングしないで処理するために十分なメモリ・キャッシュが Mobile Link サーバにあることが重要です。Mobile Link サーバのメモリ・キャッシュを設定するには、-cm オプションを使用します。
-cm オプションを参照してください。
十分な処理能力を Mobile Link に確保して、Mobile Link サーバの処理がボトルネックにならないようにしてください。通常、Mobile Link サーバで必要とされる CPU 処理能力は、統合データベースの場合に比べて非常に小さくてすみます。ただし、Java または .NET のロー・ハンドリングを使用する場合は、Mobile Link サーバの処理要件が増えます。実際には、ボトルネックの要因になることが多いのは、ネットワークの制限やデータベースの競合です。
ビジネス・ニーズに合う最小の冗長ロギングを使用してください。デフォルトでは、冗長ロギングは設定されておらず、Mobile Link はディスクにログを書き込みません。ロギングの冗長性を制御するには、-v オプションを使用します。また、-o オプションか -ot オプションを使用すると、ファイルへのロギングを有効にできます。
冗長ログ・ファイルの代わりに、Mobile Link モニタで同期をモニタできます。Mobile Link モニタは Mobile Link サーバと同じコンピュータ上になくてもかまいません。また、モニタ接続が Mobile Link サーバのパフォーマンスに与える影響はほとんどありません。Mobile Link モニタを参照してください。
TCP/IP を介してサーバがサポートできる同時接続数は、オペレーティング・システムによって制限されます。1000 を超えるクライアントが同時に同期しようとしたときにこの制限に達する可能性があります。この制限に達すると、オペレーティング・システムで予期しない動作が発生する可能性があります。たとえば、接続が予期せずに終了したり、接続しようとするクライアントが拒否されたりします。この動作を防ぐには、-sm オプションを使用して、オペレーティング・システムの制限よりも少ない数をリモート接続の最大数として指定します。
クライアントは、-sm オプションで指定された同時同期の最大数をすでに受け入れている Mobile Link サーバと同期しようとすると、エラー・コード -85 (SQLE_COMMUNICATIONS_ERROR) を受信します。クライアント・アプリケーションはこのエラーを処理して、数分後に接続を再び試みます。
-sm オプションの詳細については、-sm オプションを参照してください。
SQLE_COMMUNICATIONS_ERROR の詳細については、通信エラーが発生しました。を参照してください。
Java または .NET の同期論理と、SQL 同期論理では、スループットに著しい差は見られません。ただし、Java と .NET の同期論理では、同期ごとに余分なオーバーヘッドが発生し、より多くのメモリが必要です。
さらに、SQL 同期論理は統合データベースが稼働しているコンピュータで実行されますが、Java または .NET の同期論理は Mobile Link サーバが稼働しているコンピュータで実行されます。このため、統合データベースの負荷が高い場合は、Java または .NET の同期論理が適していることがあります。
ダイレクト・ロー・ハンドリングを使用して同期すると、Mobile Link サーバの負荷が高くなるので、ダイレクト・ロー・ハンドリングの実装方法によっては、必要な RAM、ディスク領域、CPU 処理能力が増える可能性があります。
一部のテーブルを他のテーブルより高い頻度で同期する必要がある場合は、それらのテーブル用に別のパブリケーションとサブスクリプションを作成します。Sybase Central で同期モデルを使用する場合、これを行うには、複数のモデルを作成します。この優先パブリケーションを他のパブリケーションより頻繁に同期し、他のパブリケーションをピーク時以外の時間に同期できます。
スナップショットではなくタイムスタンプ同期を使用するなどして、必要なローだけをダウンロードするようにしてください。不要なローのダウンロードは無駄であり、同期のパフォーマンスに悪影響を及ぼします。
統合データベースのスクリプトを実行するときのパフォーマンスは重要です。テーブルに対してインデックスを作成し、アップロード・カーソル・スクリプトとダウンロード・カーソル・スクリプトによって必要なローだけが効率的に特定されるようにすると便利です。ただし、インデックスが多すぎるとアップロードに時間がかかります。
Sybase Central で同期モデル作成ウィザードを使用して Mobile Link アプリケーションを作成する場合、モデルを展開すると、インデックスがダウンロード・カーソルごとに自動的に定義されます。
SQL Anywhere クライアントの場合、多数のローをアップロードするときは、アップロードするロー数の推定値を dbmlsync に指定すると、アップロード速度を大幅に改善できます。この操作には、dbmlsync -urc オプションを使用します。
-urc オプションを参照してください。
| Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |