FileMaker でレスポンシブなWebアプリを作る

　FileMaker（以下、FM）のデータベースを FileMaker Pro 以外のクライアント ― ブラウザ、iPhone/iPad、Android ― でも運用する場合、開発環境をFMにすべきか、カスタムWeb にすべきかを考えると思いますが、その際に考慮べき事項を比較表にまとめてみました。

×: terrible,  △: limited,  〇: OK,  ◎: Excellent

	Go	WebDirect	Custom Web
開発費用 (Devlopment cost)	◎	◎	×
ライセンス費用 (License cost)	×	×	◎
サーバ機費用 (Server machine cost)	×	×	◎
ライセンス体系 (License policy)	×	×	◎
開発の容易さ (Ease of development)	◎	◎	×
コードの再利用性 (Code reusability)	×	×	◎
開発の柔軟性 (Development flexibility)	×	×	◎
レスポンシブ性 (Responsive Web Design)	×	×	◎
Android等非iOS機との互換性 (Android compatibility)	×	△	◎
スケーラビリティ (Scalabilty)	△	×	◎
他DBへの移植 (Migration to other DBs)	△	△	◎

この表からは、

圧倒的ではないか、カスタムWebは

という感じですが、FMの世界では「開発費用」と「開発の容易さ」が他の要素を圧倒し、Go やWebDirect が採用されやすいのではないでしょうか。逆に言えば、他の要素が重要なプロジェクトでは、FMは使用されないのです。
　
　とは言いいつつ、 FM のカスタムWeb という需要は少なからずあり、またスマホ普及に伴う Mobile First な要望もあり、小社としてもまたーりとそれらにお応えしたい、と愚考している次第です。
　そんなわけで、『FMEasy在庫 IWP/WD R1.5』（以下、FMEasy在庫）をバックエンドに使用し、 iPhone/iPad だけではなく Android 等の非iOS デバイスにも対応したレスポンシブな Webアプリのプロトタイプ開発にトライしていきたいと思います。

開発環境

使用データベース： FileMaker(fmp12)
使用ライブラリ： jQuery、ｊQuery Mobile
対応デバイス： PC、タブレット、スマホ（非iOSデバイスを含む）

開発方針・目標

第１フェイズ

以下の方向で、FMEasy在庫の出庫関連機能をWebアプリ化→プロトタイプを作成する。

1. マルチデバイス対応、RWD(Responsive Web Design)採用
   たとえばこんな感じで……。
   
   【PC利用時】
   
   

   

   Windows Chrome

   
   
   【タブレットPC利用時：縦置き】
   
   

   

   Nexus 7, Android, Chrome --- Portrait

   
   
   【タブレットPC利用時：横置き】
   
   

   

   Nexus 7, Android, Chrome --- Landscape

   
   
   【スマートフォン利用時】
   
   

   

   FreeTel Priori 3, Android, Chrome

   
   
2. XML/fx.php/FM API for PHP/PDO（ODBC）の比較テストを適時実施
   　→最適なAPIを決める（努力をする）
3. 出庫伝票照会機能作成
4. 出庫伝票追加・更新機能作成
5. 出庫伝票検索機能及び一覧表示機能作成
6. 出庫伝票PDF出力機能作成

第２フェイズ

1. 第１フェイズで作成した機能をライブラリ化
2. ライブラリを他のDBへ対応させる（PDOなら簡単なんじゃないかな）

第３フェイズ

1. 上記ライブラリを使用することにより、お客様にレスポンシブなシステムをリーズナブルな価格で提供する
   ＼(^_^)／

　いろいろ書いてますが、予定は未定ですｗ

本ブログの関連記事について

　本ブログで今後公開予定の RWD によるカスタムWeb関連の記事は、カスタムWeb による開発を検討されているお客様に小社で開発したプロトタイプの仕様やテスト結果をご覧いただき、プロジェクト検討の一助になることを目指しています。

ということで、次回はこのプロトタイプの照会機能についてご紹介したいと思います。

（亀）　

WebDirect 14 vs 15 ― JMeter による負荷テスト

　FileMaker インスタント Web の後継版として、FileMaker 13 より WebDirect （以下、WD）が登場しました。インスタント Web に比べ、 WD の操作性はより FileMaker Pro に近づいたものの、パフォーマンスや安定性にかなり問題があるんじゃないか、みたいなことを約1年前に記事にしました。 その折は、WD13 と WD14 の2つのサーバ上で、複数のクライアントPCを用意し、各PCで複数のブラウザウインドウを開いた状態で、それぞれのウインドウからスクリプトを手動実行して負荷をかける、というものでした。
　今回は Apache JMeter （以下、JMeter）というパフォーマンステストツールを使用し、WD14 と WD15 のパフォーマンス比較をしたので、以下にその内容をレポートします。WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果

　今回のテストでは、小社製品「FMEasy在庫 IWP/WD R1.5」を使用し、出庫伝票を作成するスクリプトを作成。JMeter によりこのスクリプトを 25 のセッションで 10 回ずつ実行し、その所要時間を測定するとともに、CPUの占有状況を観察しました。　また、このテストは FileMaker 14 と 15 の双方で行うとともに、サーバのリソース（コア数とメモリ）を増やすことにより、パフォーマンスがどの程度改善するかも測定しました。

仮想サーバ構成

　CPU： 3.0Ghz
　コア数/メモリ： 1core/2GB、2core/4GB、4core/8GB　の3パターン
　Windows Server 2012 R2 (64bit)

JMeterシナリオ

　JMeter により、「FMEasy在庫 IWP/WD R1.5」の出庫伝票を1つ作成後にログアウトするスクリプトを以下のシナリオに基づき実行。　

　Threads： 25
　Loops：10
　Ramp-up：1sec
　Pause： 1sec or 1.5 sec

注：

• Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15 では 1 秒、WD14 では 1.5 秒 の Pause　時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。この点からも、WD15 のパフォーマンスが改善していることがわかります。
• シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、下表に記載しています。

テスト結果

WebDirect 14 vs 15 出庫レコード作成時のパフォーマンス（Fails は作成に失敗したレコード数）

Peformance comparison graph on CPU cores and memory

考察

※WD14 vs WD15 の比較

　サーバリソースにかかわらず、WD15 は WD14 に比し、30%程度実行速度が改善されました。

※サーバリソースと実行速度の改善

　サーバリソースを 1core/2GB から 2core/4GB に増やすと、WD15 で約 50%、WD14 で約 40%、実行速度が改善されました。
　さらにリソースを 2core/4GB から 4core/8GB に増やすと速度は改善されたものの、改善率はそれぞれ 20%弱と 15%弱となりました。このことから、リソース割り当てを増やせば実行速度は改善するが、その改善率は徐々に鈍化するものと推定されます。

　

※ CPUの占有率

　以下の図は JMeter 実行時の CPU 占有率です。　1コアの場合、CPU を使い切ってしまうことが多々ありました。やはり、CPU 占有率が 100%になるような状況は避けたいです。リソースを増やすに従い、CPU の使用率は下がります。


FM WebDirect 15

1 Core / 2 GB RAM

CPU 占有率が 100% に達する状態が続く。同時アクセスユーザが集中する可能性のあるサーバは要注意。

2 Core / 4GB RAM

4 Core / 8GB RAM

---

FM WebDirect 14

1 Core / 2 GB RAM

長時間にわたり高負荷状態が発生。WD15 に比べると処理により多くのサーバリソースを消費することがわかる。

2 Core / 4GB RAM

4 Core / 8GB RAM

JMeter テスト環境と運用環境の違い

　最後にJMeterテスト環境と実際の運用環境との違いについて簡単に触れます。下図左のグラフは JMeter でにより伝票作成スクリプトを 1 セッションで 1 回実行したときのもので、右のグラフはブラウザ上から手動により伝票作成スクリプトを1回実行したときのものです。サーバのリソースは共に 1core/2GB です。 JMeter では CPU のピーク時の占有率が約 20%であるのに対して、ブラウザでは 80％弱となっています。

　今回は WD14 と WD15 の比較とサーバリソースの増減によるパフォーマンスの変化をテーマとしているためあまり問題ではないと思いますが、実際の運用環境を JMeter によりシミュレートしようとする場合は、JMeter のシナリオを如何に運用環境に近づけるかが大きな課題となります。ただ、JMeter は実行するタイミングによってパフォーマンスにばらつきが出たり（実機でもそうですが）、シナリオを WD の運用環境に近づけるのはかなり難しかったりするため、その差分を係数化し、JMeter ではその係数分の負荷を余計にかける、などの補正が必要かもしれません。
　たとえば、下図のような状況であれば係数を 0.25 とし、運用環境で 20 ユーザが 10 秒間に 1 回レコード保存を実施すると想定されるのであれば、Ramp-up は 10 秒ではなく、2.5 秒に設定し、必要な回数のループを実行する、というのは一案と思われます。　


　それでも納得できないお客様に遭遇してしまった場合ｗは、必要台数分の仮想マシンや VDI 環境を用意し、FileMaker スクリプトを各仮想マシンから一斉に実行するような仕掛けが必要になるかもしれません。
　

その他の情報

ここでは、今回の JMeter による WD パフォーマンス測定で得られたその他の情報をまとめます。

1. JMeter で WebDirect にリクエストを発行すると、タイムスタンプが狂う
   
   レコード作成日時を記録するためのフィールドをタイムスタンプ型にしておくと、JMeter 経由で WD のレコードを作成／修正すると、タイムスタンプが協定世界時刻（UTC）になってしまうことがあります。
   
   

   

   この設定では、JMeter 経由でのレコード作成時に協定世界時が記録されてしまう

   
    つまり、日本時刻では 9 時間のズレが生じることになりますが、以下のようにホストのタイムスタンプを自動入力させることでこれを回避できます。
   
   

   

   Get( ホストのタイムスタンプ ) を計算値として自動入力することで時刻の狂いを回避

   
   または、Get ( 現在の時刻 UTC ミリ秒 ) を使って日本時間を算出することもできます。
   
   計算式：
   GetAsTimestamp ( ( Get ( 現在の時刻 UTC ミリ秒 ) + ( 9 * 3600000 ) ) / 1000 ) 
   
   
2. WD14 と WD15 の挙動の違い
   
   WD14 でレコードを作成したり、修正したりすると、FileMaker で記録されるユーザ名は [WebDirect] ですが、WD15 では [WebDirect-XXXXX]という形式でユーザ名が記録されます。
   
   この XXXXX の部分は WD 実行時のセッションID（32桁、16進数文字列）の最後の 5 桁となり、各 WD ユーザを識別しやすくなっているといえるでしょう。
   
   FileMaker Pro 15 のヘルプにもこの解説がありますので、興味のある方は参考にしてみてください。
   
   Get ( ユーザ名 ) の説明
   Get ( 持続 ID ) の説明
   
   

　その他の WebDirect 関連記事を読む

(亀)

API 別/サーバ別FileMaker カスタムWebパフォーマンス比較

 FileMaker で カスタムWeb を構築する場合、どの API が一番高速なのか、と疑問を持たれてきた開発者の方も多いかと思いますが、小社もその一員です＞＜。「FM社がバンドルしてるんだから FileMaker API for PHP なら、まぁ、間違いないだろう」位のノリでそれを採用してしまったりとか。FileMaker API for PHP（以下、FM API for PHP） や FX.php なら、ネット上の情報量も多いですし。
　そんな折、FM API for PHP を使用してWeb システムを構築していたわけですが、JMeter で想定される最大負荷をかけたところ、Web サーバがダウンしてしまうことがありました。　幸い、実運用ではそのような状況には今のところ陥っていないのですが、「これは一度、4つの API で比較テストしておこう」ということになり、今回、その運びとなりました。　また、同テストを FileMaker Server 12 と 15 でも実施しました。以下にその方法と結果を公開いたします。　1ユーザによる郵便番号データの検索と表示という限られたテストなのですが、多少なりとも参考になればウレシイかも、です。

1.　テスト方法

全国の郵便番号データを入れた FileMaker データベース（今回は弊社製品『FMEasy在庫』の郵便番号テーブル）を用意し、FileMaker Server 12 と 先月リリースされたばかりの FileMaker Server 15 でそれぞれ公開。
　このデータベースにアクセスして郵便データを検索するための簡単な php ページを作成しました。

　たとえば、FileMaker API for PHP で「北海道」を含む郵便データを検索するときのイメージはこのようになります。

検索実行中！

　そして下図が実行結果となります。
　FileMaker API for PHP による「北海道」郵便データ検索結果は 8242 件（データはかなり古いので、最新のデータでは違う結果が返ると思います）で、このレコードを取得してくるのに 2.9935 秒かかったことがわかります。

2.　テスト結果

FileMaker　Server 12 と 15 を使用し、それぞれのサーバ上で XML、FileMaker API for PHP、fx.php、POD(ODBC) の 4 種類の API を使って 10 回ずつ「北海道」の検索を実施しました。
　その測定結果は次の通りとなりました。

　FileMaker Server 12 と 15 のバージョン間の比較では、FileMaker Server 15 のパフォーマンスが約30% 良い結果となりました。

　パフォーマンス平均をグラフ化すると、このようになります。

API 別 FMS15 vs FMS 12 パフォーマンス比較

　次に、API の比較ですが、本テストに限っては、PDO が圧倒的に高速でした。北海道に属する全8242レコードの検索・描画の最高速は 0.938秒。　正直、FileMaker の ODBC を介したアクセスは使い物にならない、と過去の経験から思い込んでいたので（その記事がこちら）、この結果は驚きでした（FMさん、御免なさい r(￣_￣;)）。　また、2つの php ライブラリでは、FX.php がほんの少し有利で、php ライブラリと 生XML の比較では、生XML が約40% 高速となりました。


　php ライブラリは、Web プログラマにとって扱いやすいというのがメリットですが、処理が関数化されていることによって、その分サーバのパフォーマンスが相当程度犠牲になっているようです。
少ない人数の運用では何ら問題が無かったのに、ユーザ数が増えた途端に業務に支障をきたすようになった、みたいな時は、DBへのクエリやコードの見直しに加えて、XML や PDO への乗り換えも選択肢になるかもしれません。


参考サイト：
FileMaker×PHPで作る、簡単・便利なWebアプリ　― とっても力作なサイト

過去記事：
ODBC ドライバ DataDirect SequeLink を使って FileMaker Pro にアクセスしたときの問題点


（亀）