2016-12-01

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に当たってみるのが正解」ということでした。


(土屋)

0 件のコメント: