はじめに
- 2017年度のFileMaker Developer Conferenceのセッション動画から、気になったものをピックアップして視聴したので、自分メモを兼ねてご紹介いたします。
- FileMaker社がYoutubeに公開しているセッション動画のYoutubeリストはこちら
他に投稿した[要約・翻訳]
Title: Under The Hood: Server Performance
-
Speaker: Jon Thatcher
-
Company: FileMaker, Inc.
Web Publishing Engine(WPE)について
FMS16からマスタ機にもWPEが入るようになった
- FMS15まで：2台構成の際には、ワーカ機にWPEが入っており、WEB側と直接通信できるのはワーカ機だった
- FMS16から：複数台構成でも、マスタ機にWPEが入り、WEB側と通信できるようになった（特定のポートだけ開けておくようにする）
- 何台で構成しても問題なく処理できるように（WebDirectのクライアントはどのワーカ機に通信してもいい）
- ワーカ機1台あたり、WebDirectのクライアントは100までぶら下がれる
- マスタ機がファイアウォールの外に出られない場合、マスタ機のWPEをOFFにせざるを得ない
FMS16でのパフォーマンスの向上
WebDirect
- 処理速度向上
- クライアント側でウィンドウサイズ変更の際に、サーバに問い合わせて再度レンダリングし直すことなく、サイズ変更がおこなえるように
その他
- テーブル、テーブルオカレンスなどの情報をローカルキャッシュできるように（FMS15までは、全て再度ダウンロードし直していた）
- ポータル表示の処理速度向上
- データベースデザインレポート生成の高速化
- ファイルアイコンなどを裏側でダウンロードするように
- FileMakerProからServerへのファイルアップロード速度向上
Perform Script On Server(PSOS)_サーバ上のスクリプト実行
概要
- ウインドウやズームなどUI関連のことはサポートしない
- そのFMSで共有しているファイルのスクリプトしか実行しないし、他のFMSで共有しているファイルは開けない
- PSOSは、スクリプト実行されたFMSの中にテンポラリファイルを生成してそこで実行させている（テンポラリファイルはスクリプトの実行終了時に削除される）
PSOSでのテンポラリファイルの取扱
- データベースサーバからテンポラリファイルを生成してスクリプト処理
- スクリプト処理が終わったらテンポラリファイルから元ファイルへ反映
- テンポラリファイルは削除される
- 要は、Pro, Go, WebDirectなど他のクライアントと同じ
PSOS実行時におこなわれること
- 以下のすべての情報がダウンロードされる
- テーブル
- テーブルオカレンス
- リレーションシップグラフ
- 呼び出し時の初期レイアウト（テーマ、スタイル、レイアウトのフィールド定義など）
- 値一覧
- フォント
- カスタムメニュー
- 以下については必要時にダウンロードされる
- 全レコード
- サムネイル
- スクリプト
- 呼び出し時でない他のレイアウト（レイアウト切り替え時に都度）
PSOS実行時に気をつけるべきこと
- 以下2つのスクリプトトリガについては、強制的に実行されるので、シンプルなものにしておくこと
- OnFirstWindowOpen
- OnLastWindowClose
- 巨大なテーブルのレイアウトを避ける
- 多くのポータルや関連テーブルフィールドを持ったレイアウトを避ける
- PSOSはRAMとCPUをデータベースと共有しているので、気をつけなくてはならない
PSOS vs FileMakerScript schedule
- 後者で代替できるなら、そうした方が良い
FileMakerのパフォーマンスについての金言
FileMakerはすべてをキャッシュする
- データベースサーバはRAMキャッシュとテンポラリファイルを持つ
- クライアントはファイルキャッシュとテンポラリファイルを持つ
- クライアント側のテンポラリファイルは21日間は再利用されうる
- ディスク容量が少ないとパフォーマンスが劣化する
- テンポラリファイルを上書きしないといけないので、何度もダウンロードのし直しがされる
- 大量レコードのソート状態などもキャッシュで持っている
- ファイルを開き直すと、クライアントはキャッシュされたレコードが有効なものかどうかチェックをおこなわないといけなくなる
- レコード内のフィールドは全てセットされた状態で一緒に読み書きされる
- つまり、フィールドの量がレコードサイズを決める
- レコードサイズが大きくなるということは、アップ／ダウンロードが遅くなる
- 100フィールドを超えるならテーブルを分けた方が良い
- あまり使われないフィールドや、テキストフィールド（特に重いので）を対象に
- 1対1関係のリレーションでも別に構わない
- なお、オブジェクトフィールドは例外
- FileMakerはツリー構造を持っており、カラのフィールドはそのレコード内で認識されない＝0byteなのであまり気にしなくても問題ない
サーバとクライアントのver.は合わせる
基本
- FMS15ならFMP15、FMS16ならFMP16、というように揃えるのが、一番パフォーマンスが良い