このセクションの記事

同期のスピードを上げるにはどうすればいいですか？

Satsuki (Splash Store ヘルプデスク)
  • 更新
フォローする

MirrorSyncをより高速にする方法について説明する前に、まず同期に影響す可能性のある動作を解説します。

同期速度に時間が影響する動作 

クライアント＝サーバー同期における最初のデバイスの初回の同期

iPad/FileMaker Pro ＝ FileMaker Serverの同期の場合

主キー、変更タイムスタンプ、作成タイムスタンプ、レコードID、レコード、およびデータベース内のすべてのテーブル内のすべてのレコードに対する変更カウント

  • 最初のデバイスの初回同期では、MirrorSyncが同期管理のための初期状態を内部データベースに書き込む初期処理が行われます。
  • 初期処理において、MirrorSyncはデータベース内のすべてのテーブル内のすべてのレコードのメタデータをダウンロードしてMirrorSync内部データベースに書き込みます。そのため、とても時間がかかります。
  • 初期処理が正しく完了後は、どのデバイスでも最初の同期開始から完了までの時間は早くなります。
  • 初期処理が実行される条件
    • クライアント＝サーバー同期構成を設定してから初めて同期を実行したとき。
    • MirroSync管理画面で作成済みの同期設定を右クリックして同期データをリセットしたとき
    • 同期設定を削除して再作成したとき

 

差分データの同期でメタデータの再スキャンが発生するとき

通常、差分データ同期は初期同期よりも高速ですが、以下のようなケースでは主キーの再スキャン処理が発生するため、同期が遅くなる場合があります。

  • 増同期中にHub/Spokeデータベースのいずれかで大量のレコードが書き込まれた場合、データベースの次回の同期には通常よりも時間がかかります。
  • レコードが削除された場合、MirrorSyncは主キーをスキャンしてどのレコードが削除されたかを確認します。削除の確認は高速ですが、大量のレコードが削除された場合は速度に影響します。

その他の時間がかかる動作

  • オブジェクトフィールドの同期は、その他のデータよりも同期に時間がかかります。
  • 同期対象のテーブルが非常に多い場合、速度に影響します。
    •  1テーブルあたり約0.5〜1秒のオーバーヘッド+実際に変更を同期する時間
    • テーブルの数と同期の所要時間は比例します。

 

同期速度を上げるためのヒント

以下のような動作は、上記であげたような動作より高速です。

同期速度に影響が少ない動作

  • データベースの新しいコピーをダウンロードしてファイルを差し替えた後に行う初回の同期は、以前に行われたコピーからの初期同期と比較してはるかに高速です。
  • 差分データの同期は初期同期よりも高速です。
  • 特にMySQLのようなSQLデータベースでは、レコードの挿入は更新よりも高速です。

特に調整をしなくてもMirrorSyncはかなり高速ですが、速いに越したことはありません。MirrorSyncからの同期のスピードをできるだけ上げるためのヒントをいくつか紹介します。

 

SSDドライブを使用する

MirrorSyncは、多くのレコードの同期を一括処理するときには細かい読み書きのオペレーションを大量に処理しています。このような使い方の場合、レイテンシーがきわめて低いSSDドライブは大いにメリットがあります。SSDドライブにMirrorSyncをインストールすると、同期が目に見えて速くなるでしょう。ハードディスク全体の代わりにSSDを使用する必要はありません。OS Xのシンボリックリンクを使ったりWindowsでインストール場所を変更したりすれば、MirrorSyncだけをSSDに置くことができます。SSDのパフォーマンスの高さにより同期の処理全般が速くなりますが、変更がごくわずか、またはまったくないような少しだけの同期を実行するときや、何十万件ものレコードがあるような大規模のデータベースの初回の同期のときには、特にめざましい効果が現れます。

fmServerOverlapSecondsを変更する

MirrorSyncは変更されたレコードをFileMaker Serverから取得するときに、前回の同期の10分前以降の変更をすべてリクエストします。この10分間の重複は、時計が遅れているユーザに対しては補正されます。前述の時間帯のセクションで紹介した「Host modification timestamp」の方法を使っている場合は、ユーザの時刻は問題にはならず、この10分間の重複は必要ありません。「MirrorSync.xml」ファイルを編集して「fmServerOverlapSeconds」のパラメータを「600」（10分間）から「5」（5秒間）の間で変更することができます。このファイルは以下の場所にあります。

Mac: /Library/360Works/Applications/conf/Catalina/localhost/MirrorSync.xml

Win: C:\Program Files\360Works\Applications\conf\Catalina\localhost\MirrorSync.xml

 

シリアル番号タイプの主キーを使用する

小さいテーブルに多くのレコードセットがある場合には特に、UUIDではなくシリアル番号を使います。5文字のシリアル番号と36文字のUUIDでは差が出ます。結合テーブルのように、ほとんどが外部キーで構成されている多数のレコードを転送するときには、特にそうです。UUIDを使う妥当な理由がある場合には、この変更はしないでください。

オブジェクトデータの同期を最小限にする

オブジェクトフィールドはデータ量が多く、オブジェクト以外のデータが一括処理されるのとは違って、個々に送信されます。同期する必要のないオブジェクトがある場合は、同期のレイアウトから削除します。

オブジェクトフィールドは、オブジェクトは変更されていないとしても、そのレコード上のいずれかのフィールドが変更されると転送されます。必要のないオブジェクトが同期されることを避けるために、オブジェクトフィールドをそれ自体のテーブルに移動します。こうすることで、オブジェクトが変更されたときのみ転送されます。

部分的な同期を検討する（可能な場合）

データベース全体ではなくレコードのサブセットだけを同期したい場合は、レコードレベルのアクセス権やスクリプト化されたフィルタを使うことができます（詳しくは後述のカスタマイズのセクションを参照してください）。スクリプト化されたフィルタを使うと、レコードレベルのアクセス権の制限に比べて、大幅に高速になります。

最新のFileMaker Server を使用する

FileMaker Server 10または11を使用している場合は、12以降に変更します。MirrorSyncとFileMaker Serverの通信はすべて、XML Web公開エンジンを経由しています。これは、FileMaker Server 11ではあまり速くありません。FileMaker Serverの最新バージョンでは、この通信が大幅に向上しています。

 

FileMaker Server 13を使用している場合はWeb公開エンジンのスローダウンを解決する 

XML Web公開エンジンに関しては、構成によってFileMaker Server 13と同期するときにかなりのスローダウンを引き起こすことがあります（FileMaker Server 10、11、12では発生しません）。これによりXMLリクエストごとに1秒長くなるので、通常は約20ミリ秒のリクエストが、1,100〜1,200ミリ秒かかることになります。この問題を解決するには「FileMaker Server/Web Publishing/publishing engine/jwpc-tomcat/conf/server.xml」のファイルを開きます。この部分を見つけます：

 

<Connector URIEncoding="UTF-8" acceptCount="100"

address="127.0.0.1"

compressableMimeType="text/html,text/css,text/plain,application/javascript,application/json"
compression="on" compressionMinSize="2048" connectionTimeout="20000"
disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192"
maxSpareThreads="75" maxThreads="150" minSpareThreads="5" port="16020"
protocol="HTTP/1.1" redirectPort="8443"/>

「address="127.0.0.1」の部分を削除します。するとこのようになります。

<Connector URIEncoding="UTF-8" acceptCount="100"
compressableMimeType="text/html,text/css,text/plain,application/javascript,application/json"
compression="on" compressionMinSize="2048" connectionTimeout="20000"
disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192"
maxSpareThreads="75" maxThreads="150" minSpareThreads="5" port="16020"
protocol="HTTP/1.1" redirectPort="8443"/>

この変更を保存し、Web公開エンジンを再起動します。http://yourServer/fmi/xml/FMPXMLRESULT.xml?-dbnames のURLでWeb公開エンジンの動作を確かめます。データベース名のXMLのリストが表示されるはずです。表示されない場合は、コンピュータを再起動する必要があるかもしれません。動作する状態に戻ったら、同期は明らかに速くなっているはずです。変更されたレコードが100件未満の場合や、変更箇所のない同期の場合には、特に速くなります。

 

レコードを削除せずフラグを立てる 

レコードを削除するのではなくフラグを立てる：MirrorSyncは、削除されたレコードを高速に検知します。しかし削除を調べるよりは、編集や挿入を同期する方が高速です。レコード数が10万件を超えるような大きなテーブルの場合は特にそうです。パフォーマンスを最適化したい場合は、レコードを実際に削除するのではなくフラグを立てるようにするとおそらく効果が見られるでしょう。これは編集の処理となり、テーブル内のレコードの件数には影響しません。

空のクローンのテーブルをあらかじめ作っておく

最初が空のクローンで初回の同期にとても長い時間がかかる場合に、空のクローンのテーブルをあらかじめ作っておくことができます。次の「オフラインのデータベースをあらかじめ作って初回の同期を速くすることはできますか？」の質問を参照してください。

 

原文：What can I do to speed up syncing? http://docs.360works.com/index.php/MirrorSync_advanced_topics#What_can_I_do_to_speed_up_syncing.3F

関連記事

コメント

0件のコメント

サインインしてコメントを残してください。

Powered by Zendesk