はじめに
FileMaker便利ですよね。手軽にアプリケーション作れて楽しいですよね。
でもある程度使ってると、いろいろ問題出てきます。中でもレスポンス遅延は
頭の痛い問題です。そんな時に確認するポイントをまとめました。
レスポンス遅延と一言に言っても、いろいろな状況が考えられるので今回は
ただ表示しているだけなのに遅い（特に一覧）、ってやつをターゲットにします。
一部対応方法も書いてますが、要件や状況で変わってくるのであくまで参考程度ということで…。
- 19.05.09 追記
- 「遅いことがある」という事象について のセクションを追加
- 19.02.15 追記
- ボトルネックの見つけ方に、スクリプトトリガを追記
- 18.09.20 追記
- ソートが原因説追加
ボトルネック（原因箇所）の見つけ方
-
Ver13以降であれば、オブジェクトの非表示を使う方法がおススメです。原因と思われるフィールドにTrueを入れて、ブラウズモードで改善が見られるか確認します。改善するならそこがボトルネックです。
-
Ver12以前であればレイアウトをコピーして、そのレイアウト上で原因と思われるフィールドを１つずつ消していきます。同じくブラウズモードで改善が見られたらそこがボトルネックです。
-
スクリプトトリガに、ボトルネックとなるスクリプトが設定されている可能性もあるので確認しましょう。
・ファイルオプション→スクリプトトリガをチェック！
・同様にレイアウト設定→スクリプトトリガをチェック！
早速ポイントを
説で分けて書きますが、どの説にも共通しているような話もあるので、全部読むことをおススメします。
《リレーションが原因説》
殆どの原因がこれと言っても過言ではないと思います。
● 複雑な条件が含まれている。
具体的には「≠、<、<=、>=、>」ですね。内部的に結合条件で検索しているような動きになるので、特に一覧で如実に遅延が見られます。
＞対応方法
- そもそも必要なTO（テーブルオカレンス※分からなかったら調べてみてね）なのか確認しましょう。いつの間にか不要になっていることも多々あるかと。
- 索引が貼られているかを確認してください。デフォルトで必要時に貼られる設定になっているはずなので、恐らく貼ってあるはずですが…。
- 結合条件を見直します。
例１）"<"だけで判断している ⇒ ">"も条件に加える余地が無いか検討
例２）日付の範囲指定で、ある月だけに絞っている ⇒ 「年」と「月」のフィールド(保存する計算フィールド)を追加して"="で検索 - どうしても条件見直しができない場合、見せる側で工夫します。例えば原因となっているフィールドを非表示にしておいて、チェックボックスを配置、ONにしたときだけ表示するとか、一覧系であれば１行の高さを高くしてみるとか（FileMakerは見えている行しか取得しないのでこれで結構早くなる）。
● リレーションが深すぎる。
＞対応方法
- これも先ずは、そもそも必要なTOなのか確認してください。
- テーブル定義見直しを検討します。リレーション先に持っているフィールドを、リレーション元にも持たせる等。
例）注文書テーブルに職員テーブルを繋いで、職員名を表示している ⇒ 注文書テーブルにも職員名を持たせる（本来は正規化の観点だと逆行していますが、FileMakerのレスポンスという観点では正と成り得ます）
《条件付書式／オブジェクトを隠す が原因説》
● 複雑なリレーションのTOが条件に含まれている。
これは結局リレーションが原因なので、「リレーションが原因説」と同じ対応方法となります。
● 計算式が複雑。
初心者であれば、レスポンスを遅延させるほど複雑な計算は書けないと思いますが、例えば再帰のあるカスタム関数を使っていたり、使用しているTOの数が多かったり が考えられると思います。
《フィールド定義が原因説》
● 計算フィールドが複雑。
これも結局他の説と根本的な原因は同じです。
● 集計フィールド使いすぎ。
内部的にかき集めて集計するので、当然レスポンスへの影響があります。
＞対応方法
- 予め集計されたテーブルを別に用意します。
- 標準関数(SumやGetSummary）で代替可能か確認します。使い方はヘルプを参照してください。
《ソートが原因説》
●レイアウトが表示されるタイミングでソートしている。
データ量が多い場合に発生します。ファイルメーカーのソートは遅いです。
＞対応方法
- 表示件数を絞り込む余地が無いか検討します。大抵は全件を表示する必要性が無いことが多いです。
- ソートボタンでソートさせます。結局ソートしなければいけない画面であれば、トータルの処理時間は変わりませんが、起動が早ければ印象が変わってくると思います。ソートが遅いということが明示的に分かれば、検索で代替するなどの工夫の余地も出てきます。
●関連レコードのソートが遅い。
結合先の件数が少なければ問題ありませんが、多いと遅延の原因となります。
＞対応方法
- ソート方法の変更を検討します（リレーションシップグラフ⇔ポータル）。ポータルでソートしている場合、クライアント側での処理になるので、速度はデバイスのスペックに依存します。端末によって遅延がある場合、リレーションシップグラフでのソートに変更すると改善が見られるかもしれません。ただし、サーバ側の負荷が上がるのでその点は意識する必要があります。
《ESSが原因説》
● データ量の多いESSを参照している。
データ量の多いESSは、そのレイアウトへ移動するだけでもかなりの時間がかかります。
＞対応方法
- 参照元のデータベースに、ある程度フィルタがかかったビューを貼る。
- ESS参照を止めて、一時表へインポートする方式に変える。この一時表を参照する。
「遅いことがある」という事象について
遅延は検索時だけとは限らず、あるデータを更新した際にも起こり得ます。
FileMakerサーバを利用している場合、常にではないがレスポンスが悪くなることがある といった経験をしたことはありませんか？私もかなりこの事象に苦しめられました。根本的な原因は上で述べたものと一緒なのですが、単体で動かしていると気付くのがとても難しいです。
FileMakerの利点でもあるのですが、ある画面を開いていて表示されているデータがどこかで更新された場合、即座に更新結果が反映されますよね。実はこの動作がレスポンス遅延を招いていることがあります。
これは私の推測なのですが（間違っていたらコメントください）、上記仕様を満たすためにFileMakerサーバはあるデータが更新された際、当該テーブルのレコードを参照している全てのクライアントへ、更新があったことを通知しています。このタイミングで内部的に再検索が行われます（正確にはリレーションの条件により、行われるパターンがある）。対象が少なければそれほど問題ではないと思いますが、数が多ければサーバの負荷は大きなものとなります。
要は大量のリクエストを同時に処理しているということです。
これによって１台ではさほど遅くない検索でも、画面が固まるほど遅くなるという事象が起こります。私が経験した「遅くなることがある」という事象の原因は、殆どがこれでした。
原因調査時に、１つのヒントとして覚えておくと良いと思います。
まとめ
先ずはボトルネックがどこなのか、見つける方法を身に付けてください。何度もやっていると大体当たりが付くようになります。そうすると、そもそも実装段階で気を付けるようになります。ボトルネックさえ見つかれば、あとはそれを避けるためにあの手この手を考えましょう。この作業はなかなか楽しかったり（早くなった時の快感）。間違いとか疑問などあれば、コメントください。
最後まで読んでいただき、ありがとうございました。
こちらも暇があればご覧ください。
FileMakerで登録／キャンセル制御したい
FileMakerで分離モデルしてみたい
FileMakerでアプリ作っていくよ【作って学ぼう】
FileMaker 一歩進んだシステム開発 -汎化-
FileMaker 一歩進んだシステム開発 - 怖くないよカスタムメニュー -