FileMaker API別にCRUDのテストをしてみた

　FileMaker をバックエンドに Webプログラミング（カスタムWeb、CWP とも呼ばれる）を行う場合、実行速度的に一番有利な API はどれか？ と悩んだ方もおられるかと思います。
　今回、FileMaker  API for PHP、XML、PDO(ODBC) を使用し、それぞれが CRUD（Create/Read/Update/Delete）に要する時間を測定してみました。みなさんが Webプログラミングを行う際の参考になればなによりです。

テスト環境

サーバ： Xeon 2.2GHz(1Core)/4GB RAM（Hyper-V 仮想マシン）
OS/Webサーバ： Windows Server 2012/IIS 8.0
FileMaker Server:  Ver 15
使用言語： PHP
使用DB： FMEasy在庫 IWP/WD R1.5 （パイロット版）
テスト概要：
CRUD（Create/Read/Update/Delete）を行う簡単な Webアプリを FileMaker API for PHP、XML、PDO(ODBC) 別に作成・実行。各テストはそれぞれ5回実施して開始から終了までの時間をプログラム上で測定。各5回の平均値を基にデータを作成しました。

FM API for PHP を使用し、100件のレコードを検索・表示した際のブラウザウインドウ（FireFox）

Readテスト 1

テスト内容
94万レコードを持つテーブルから該当件数が N 件になるように検索し、その中から100レコードのみを表示

結果：　XML圧勝！　PDO惨敗

No. of　found recs APIs	0	15000	30000	300000	600000	900000
FM API for PHP	0	0.22	0.34	1.76	3.28	4.74
XML	0	0.19	0.25	1.68	3.26	4.71
PDO	0	0.65	0.72	2.47	4.18	5.91

補足
折れ線グラフではあまり目立ちませんが、該当件数が少ない場合、FM API for PHP または XML を使用したほうがPDOより3倍程高速であることが上表のオレンジ部分から解ります。表示する件数が100ほどの場合、検索時の該当件数（resultset）が増えるに従い、FM API for PHP / XML のPDOに対する優位性が薄れます。

Readテスト 2

テスト内容
94万レコードを持つテーブルで 該当件数が3万件になるように検索し、N 件のレコードを表示

結果：　FM API for PHP と XML が有利

No of fetched          　　        recs APIs	0	100	500	1000	2500	5000	7500	10000
FM API for PHP	0	0.34	0.81	1.36	4.32	6.99	10.51	Error
XML	0	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	0	0.72	0.74	1.28	3.45	5.18	7.46	10.24

補足

100件の表示を行うのであれば、FM API for PHP と XML が有利ですが、表示件数が2500になると PDO の優位性が出てきます。ただ、画面上に2000件以上のレコードを表示する Webアプリ はあまりないと思われるので、FM API for PHP と XML に軍配を上げました。

注：
以前、郵便番号検索アプリを使用し、「北海道」を検索してレコードを表示するテストをAPI別に行いました。「北海道」を検索すると8000件強のレコードが検索されるので、このようなケースではPDOが優位となります。Webサーバの負荷を考えると、8000件一括表示は普通やらないほうが良いでしょう。

Create テスト 

テスト内容：
94万レコードを持つテーブルに対して 100件のレコードを PHP のループにより作成。その後、作成した100件のレコードを検索して表示。

注：
レコードを1件のみ作成するテストもやってみようかと思ったのですが、1件のみでは一瞬で処理が終了してしまい、他のプロセスが測定結果に大きく干渉すると思われたため、100件のレコードを作成することにしました。

結果：PDOの圧勝！

Delete テスト

テスト内容：94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ削除。PDO では DELETE table WHERE ～により、100件を一度に抽出して一括削除。

結果：　PDO圧勝！

Update テスト

テスト内容：

94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ更新。　PDO では　UPDATE table SET ～ WHERE ～により、100件を一度に抽出して一括更新。　更新後、更新対象となったレコード100件を検索して表示。

結果：　PDO圧勝！

まとめ

 上記のテストより、Read（検索/表示）では FM API for PHP/XML が有利であることがわかりました。　Create/Update/Delete では PDO（ODBC） が有利でした。
API使用のガイドラインは以下のようになると思われます。

1. 基本は、FM API for PHP を使用する
   XML は FM API for PHP より高速ですが、結果セット（resultset）の処理が面倒。
2. 2000件を超えるレコードを表示したり、数十以上のレコードを頻繁に Create/Update/Delete するアプリでは、PDO（ODBC）を使用する 

　また、FM API for PHP/XML のクエリ機能は貧弱なので、SQL を使用しないと実現が面倒な DISTICT や UNION 等の処理については、PDO（ODBC）の使用を検討すべきでしょう。逆に、FileMaker ODBC で内外結合（JOIN）を行い結合先のテーブルに対してクエリを行うと恐ろしく速度が劣化します。JOINを使うのであれば、FM API for PHP により 関連テーブル（TO）にアクセスしましょう。　

　今回のテストを通じて感じたのは、「実行速度に問題が生じた場合は、1つのAPIに固執せず、別のAPIに当たってみるのが正解」ということでした。

（土屋）