Webサイトを「商売道具」として活用されているお客様は、その機能やスピードの向上はそのまま売上に影響する。さらに、お客様に「ファイルメーカーWeb公開ソリューション」を商品としている会社にとっても、「ファイルメーカーは遅い」という不評はそのまま会社の売上にも影響する。
ファイルメーカーのWeb公開表示スピードアップを考えるとき、
１）フィールドの索引（インデックス）設定をオンにする
２）使用しないフィールドはレイアウトから外す
３）数万文字のテキストが入っているようなフィールドは検索から除外する、
可能であれば代用のキーワードフィールド等を作成する。
４）早いCPU、ハードディスク、ネットワークなどインフラ整備
といったことが基本設定として重要である。
４）のケースで考えると、処理の重い検索や集計などのリクエストが入ると、CPUがフル稼働になり、待ち時間に絶えられなくなったユーザーからのリロードも発生し、悪循環のサイクルに突入する。とくにFM Web Publishing Engineの負荷は相当なようで、常時CPUとメモリの資源を消費し、スレッド数も増えてくる。そうなると、4GB以上のメモリ、最新の高速マルチコアCPUといった設備が必須になってくる。
しかし、ハードの充実以上に、やはりデータベースやスクリプトの構造を見直すのが賢明だ。そこで、１）の対応策として、リレーショナル、集計関数などどうしても索引設定ができないフィールドの問題を考えてみたい。
一つの例として、足を引っ張るフィールドをそのままWeb公開に使わない方法がある。
例えば、「今月の売上集計」をWebで表示させる場合、ファイルメーカーの視点だけで考えると、ファイルメーカー上で日々の集計用フィールドを作り、そのフィールドをWeb公開すると考えられる。
しかし、ここで集計作業をファイルメーカーに計算させると、索引設定ができないフィールドに対して１日の集計x日数分の計算で、表示時間がかかってしまい、恐ろしい結果になる。
そんな時は、ファイルメーカーの集計用フィールドを表示するのではなく、ファイルメーカーから送出された１日のデータをPHP側で計算させればよい。
さらに、その結果をカレンダー形式で表示したい場合も、あえてファイルメーカー側で365日の関連テーブルを作る必要はない。PHP側で表示分の日数の配列を作り、その配列処理の中にファイルメーカーの検索結果を含めて表示させれば、無駄な日数分の検索作業をファイルメーカーにさせる必要は無くなる。
ファイルメーカーのメリットは使いやすさではあるが、その機能に頼りすぎないことがポイントということだろう。
|
