2016-06-15

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 秒に設定し、必要な回数のループを実行する、というのは一案と思われます。 


 それでも納得できないお客様に遭遇してしまった場合wは、必要台数分の仮想マシンや 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 ) の説明



(亀)

2016-06-06

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 にアクセスしたときの問題点


(亀)

2016-05-25

FileMaker 5.5/6 をモバイルで使う

 FileMaker 15 がリリースで盛り上がる?中、前回は FileMaker 5.5/6 って最高!という記事を書きました。

 開発サイドとしては、機能強化された最新の FileMaker を利用していただけると助かるのですが、コスト、対応デバイス、環境変更の手間等々の事情により、そう簡単にアップグレードできない企業・組織ユーザも多いのでは、と思われます。そうしたユーザの中には「現行の FileMaker システムは順調に稼働しているので苦労してアップグレードはしたくない。でも、モバイルでは利用したいよね」、みたいなところもあるのではないかと思います。

 そんなわけで、「この会社は一体何を考えているのか」という冷ややかな視線を感じつつ、今回は FileMaker 5.5/6 によるモバイル使用を試してみます。
 とは言いつつも、モバイル用のリモートデスクトップアプリを介してFM5.5/6を使用する、というだけなので、「なにを今さら」と思う方もいらっしゃると思います。小社でも以前、いくつかのリモート接続ツール(Remote とか iRdesktop とか iTapRDP )を試してみて、「これでFMデータベース操作するのは厳しい」と思い込み、最近は完全ノーマークでした。ところが Microsoft 社からリリースされているモバイル用 Remote Desktop Client というアプリを恥ずかしながら最近知り、これならなんとか使えるかも、と思い始めた次第です。

注:
言わずもがなですが、iPhone/iPad 上のFileMaker Go を使用すれば FileMaker Server に直接接続できます。本稿は、FileMaker Go は利用できない、あるいは Android やSurface で FileMaker を使用したいという方向けへの記事ともなっています。 

概要と準備するもの


 モバイル機器からの FileMaker データベース接続イメージはこのようになります。

モバイル機器による旧バージョン FileMaker データベース接続イメージ

 上記のように構成する場合は、以下の環境が必要となります。


 FMモバイルアクセス環境
  1. FileMaker Server
  2. FileMaker Pro アプリケーション(クライアント数分のライセンスが必要)
  3. タブレットPCやスマートフォンなどのモバイル機器
  4. リモートデスクトップサーバやVDI等の仮想デスクトップ環境(ここで FileMaker Pro を起動し、サーバにアクセス)
  5. モバイル用Microsoft Remote Desktop(Android / iOS

 FileMaker Server、FileMaker Pro、仮想デスクトップ環境(上記4)の各種設定の説明は省略しますが、 仮想デスクトップ環境では、下図のようにPC のプロパティより「リモートの設定」を選択してリモート接続を許可する点にご留意ください。




操作手順


 今回は FileMaker Server 5.5でデータベース(本例では、小社の旧商品「売上猫くん 4.5」(FileMaker 5.5/6対応)を公開し、仮想デスクトップ環境を介してAndroid タブレット PC (Nexus7)からアクセスする方法を順を追ってご紹介します。

  1. タブレット PC に Microsoft Remote Desktop アプリをインストールします。

    Google Play を開き、MS Remote Desktop を検索し、インストールします。



    【iOS用の Microsoft Remote Desktop アプリ】

    iOS をご利用の方は、Apple ストアから Microsoft Remote Desktop アプリを入手してインストールすれば、同様に操作できるようになります。

  2. RD Client アイコンをタップします。

    ホーム画面に RD Client アイコン(←Microsoft Remote Desktop のアイコン)が表示されますので、これをタップします。


  3. リモートデスクトップ接続を追加します。

    Remote Desktop Client アプリが起動します。
    画面右上の+アイコンをタップします。


  4. Desktop を選択します。

    追加可能な項目の一覧が表示されますので、その中から Desktop を選択します。

  5. リモートデスクトップ接続情報を入力します。

    表記はすべて英語となりますが、最低限接続先のPC名(または IP アドレス)とユーザ名を設定するだけでも接続できるようになります。

    下図では、フレンドリ名として nekodemo を入力していますが、これは必須ではありません。



  6. 共有先の Windows PC に接続します。

    接続情報を保存すると、nekodemo という名前のアイコンが画面に追加されますので、これをタップします。

  7. ログイン情報を入力します。

    共有先の PC に接続すると、ログインダイアログが表示されますので、Windows PC へのログイン情報を入力し、“Connect”ボタンをタップします。



    ※このアプリの仕様と思われますが、接続後の画面設定は縦置き表示ができないため、以降は、デバイスを横置きにした状態で操作を進めます。
  8. マウスポインタをタッチパネルに切り替えます。

    ログインに成功すると、おなじみのリモートデスクトップ画面がモバイル PC 上に表示されます。



    画面上部のポインタ切り替えアイコンをタップします。すると、画面表示が以下のように変わります。

    画面右の“Touch”アイコンをタップすることによって、マウスポインタをタッチパネルモードに切り替えます。

  9. ズームインモードに切り替えます。

    モバイル PC 上のリモートデスクトップ画面はとても文字が小さいという難点があります。
    リモート共有 PC側でフォントサイズを大きくしても、これは Remote Desktop アプリでは有効にならないため、文字サイズは小さいままとなります。

    ここで、ズームモードに切り替えて操作してみましょう。
    画面上部の虫眼鏡アイコンをタップします。

    すると、デスクトップがズームインされ、画面に十字矢印のアイコンが表示されます。



    この十字矢印に指を乗せて画面をなぞることによって、デスクトップの表示領域を移動します(多少の慣れが必要です)。
    以降、しらばらくはズームイン状態のまま操作します。
  10. FileMaker 起動後、スクリーンキーボードを使って『売上猫くん4.5』にログインします。

    画面上の FileMaker Pro 5.5/6.0 アイコンを二回連続でタップすると、FileMaker Pro アプリケーションが起動します。
    共有ファイルより、『売上猫くん4.5』のメニューファイルを開きます。

    以下は FileMaker Server 5.5 で公開されている『売上猫くん4.5』のログイン画面が表示されたところです。
    [パスワード]入力ボックスをタップしてもスクリーンキーボードは表示されませんので、画面上部に配置されているスクリーンキーボードアイコンをタップします。



    スクリーンキーボードが表示されますので、パスワードを入力して Enter キーをタップしてログインします。

  11. 『売上猫くん4.5』を操作してみます。

    リモートデスクトップ共有で『売上猫くん 4.5』を操作しているため、ご覧のようにファイルメーカー Pro のメニューバーは表示されたままの状態となります。



    “顧客(仕入先)”ボタンをタップすると、顧客仕入先画面が表示されます。
    ご覧のように、表示はモバイル PC 用に最適化されていないため、画面の一部が切れた状態となります。



    ここで、画面上部に表示されている虫眼鏡アイコンをタップすることにより、ズームイン状態を解除します。



    これにより、デスクトップ全体表示に戻ります。
    各画面の情報照会はズームインモード、一覧データを照会する際はデスクトップ全体表示にするなど工夫が必要かもしれません。

    (参考:住所録表示)

  12. 日本語入力に切り替えて、テキストを入力します。

    Remote Desktop アプリケーションは、接続直後の入力モードは英語(EN)となります。
    日本語のテキストを入力するには、日本語入力モードに切り替えてから使用する必要があります。



    リモートデスクトップの右下に表示されている EN アイコンをタップし、JP (日本語)に切り替えます。

    そして、日本語を入力したい画面のテキストボックスをタップし、手順10.の要領で画面上のキーボードアイコンをタップしてスクリーンキーボードを呼び出します。

    このとき、お使いのモバイル PC によってはキーボードが英語のままになっているため、キーボード下部の English をタップすることによって、日本語キーボードに切り替えます。





    日本語入力をしてみましょう。以下は「てすとにゅうりょく」とローマ字打ちしてから、候補の中から「テスト入力」を選ぼうとしているところです。



    ご覧のように、[備考]フィールドに「テスト入力」と入力できました。


 以上、使い勝手はモバイルに最適化されたFileMaker Go にはかないませんが、モバイル版Microsoft Remote Desktop による FileMaker データベースの操作は、想像以上に快適に思いました。もともとリモートデスクトップはLAN上の仮想デスクトップで処理を行い、画面イメージのみをリモート端末に送るので高速です。また、モバイル機器に比べて、プリンタ等の周辺機器もPC同様に使用できるメリットもあります。
 種々の事情から FileMaker Go を利用できないユーザの方は、Microsoft Remote Desktop の利用を検討されてはいかがかと思います。

 時間があれば、旧FileMaker のアプリをモバイル用に無理やりカスタマイズしたらどのくらい操作性が向上するのか、とかも記事にしたいなぁと思っています。
 
 なお、セキュアなモバイル接続については、下記のページが参考になるかと思います。
 最終回 遠隔地のAndroid/iOS端末から社内PCにリモートデスクトップ接続する (1/2)



■ FileMaker 5/6等レガシーシステム関連記事
下記記事のレガシー延命スキームの実施と結果について。

Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
 
今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。



参考リンク:
Microsoft Remote Desktop アプリダウンロードページ(Android)
Microsoft Remote Desktop アプリダウンロードページ(iOS)


土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。ご希望の方はこちらからお問い合わせください。


(亀)