今回は 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
2 Core / 4GB RAM
4 Core / 8GB RAM
FM WebDirect 14
1 Core / 2 GB RAM
2 Core / 4GB RAM
4 Core / 8GB RAM
以下の図は 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 パフォーマンス測定で得られたその他の情報をまとめます。- JMeter で WebDirect にリクエストを発行すると、タイムスタンプが狂う
レコード作成日時を記録するためのフィールドをタイムスタンプ型にしておくと、JMeter 経由で WD のレコードを作成／修正すると、タイムスタンプが協定世界時刻（UTC）になってしまうことがあります。
この設定では、JMeter 経由でのレコード作成時に協定世界時が記録されてしまう
つまり、日本時刻では 9 時間のズレが生じることになりますが、以下のようにホストのタイムスタンプを自動入力させることでこれを回避できます。
Get( ホストのタイムスタンプ ) を計算値として自動入力することで時刻の狂いを回避
または、Get ( 現在の時刻 UTC ミリ秒 ) を使って日本時間を算出することもできます。
計算式：
GetAsTimestamp ( ( Get ( 現在の時刻 UTC ミリ秒 ) + ( 9 * 3600000 ) ) / 1000 )
-
WD14 と WD15 の挙動の違い
WD14 でレコードを作成したり、修正したりすると、FileMaker で記録されるユーザ名は [WebDirect] ですが、WD15 では [WebDirect-XXXXX]という形式でユーザ名が記録されます。
この XXXXX の部分は WD 実行時のセッションID（32桁、16進数文字列）の最後の 5 桁となり、各 WD ユーザを識別しやすくなっているといえるでしょう。
FileMaker Pro 15 のヘルプにもこの解説がありますので、興味のある方は参考にしてみてください。
Get ( ユーザ名 ) の説明
Get ( 持続 ID ) の説明
(亀)
0 件のコメント:
コメントを投稿