今回は、FX.php/APIの違い - レコード検索(2), (3)で作成した2つの検索/一覧PHPを使用し、動作のパフォーマンス・サーバにかかる負荷を比較する。
比較パターンについて
レコードの登録や編集と違い、検索処理にはパフォーマンスに影響する要因がいくつかある。
- レコード数の多少
- レスポンスレイアウトに配置しているフィールド数の多少
- 計算・集計フィールドの有無
- ソート指定の有無
今回はもっとも最小構成の「総レコード数が少ない」「レイアウトに配置しているフィールドが少ない」「計算・集計フィールドを使用しない」「ソートを使用しない」4点で検証をおこなった。これ以外のパターンについては追って検証していきたい。
FX.php / APIでのパフォーマンス測定
ここでの動作環境は次のとおり。
サーバPC (FileMaker Server)
- OS: Mac OS X 10.6.2
- CPU: 2GHz Intel Core 2 Duo
- メモリ: 6G
- FileMaker Server: 10.0.2.206
- 負荷測定: アクティビティモニタ, iostat(8) (iostatのインターバルは1秒)
クライアントPC
- OS: Ubuntu 9.10
- CPU: 2GHz Intel Atom CPU Z550
- メモリ: 2G
- 負荷測定: Apache JMeter 2.3.4
FileMaker ファイル環境
- 総レコード数: 50件
- レスポンスレイアウトに配置しているフィールド数: 9
- 計算・集計フィールドの有無: 無し
- ソート指定の有無: 無し
クライアントPCからApache JMeterを使用し、(2), (3)で作成したfx_find.phpとapi_find.phpにアクセス、応答速度などを計測する。
- 同時使用ユーザ数(スレッド数); 10, 20, 30, 40, 50
- リクエスト回数: 1回
- ループ数: 100
前回のパフォーマンス検証同様、1回のテストでfx_find.phpとapi_find.phpにそれぞれ1,000~5,000回、個別にアクセスして結果を解析。サーバPC側ではアクティビティモニタとiostat(8)を使用し、CPU使用率を監視した。結果は次のとおり。
サーバマシンのCPU使用率 (アクティビティモニタ)
それぞれ左がfx.findphp (FX.php)、右がapi_find.php (FileMaker API for PHP)の負荷となっている。
検索処理は登録処理と比較するとやはり複雑なのか、CPU使用率は同時使用ユーザ数が10でもfx_find.php/api_api.phpともに80-100%前後の負荷がかかった。
サーバマシンのユーザプロセスによるCPU使用率 (iostat)
iostat(8)の結果よりユーザプロセスによるCPU使用率を抜きだし、グラフ化した。
FileMaker APIはFX.phpと比較すると常に高い負荷がかかっており、その時間も長い。同時ユーザ数がすくない場合はその差は小さいが、40~50ユーザが同時に負荷をかけた場合、かなりの差がでる結果となった。
クライアントPCパフォーマンス - fx_find.php
同時使用ユーザ数 | 総リクエスト数 | Average[ms] | Min[ms] | Max[ms] | Std. Dev. | Throughput/sec | KB/sec | Time |
---|---|---|---|---|---|---|---|---|
10 | 1,000 | 382 | 60 | 6214 | 587.27 | 24.1 | 96.84 | 00:41.38 |
20 | 2,000 | 673 | 61 | 16270 | 1581.49 | 26.2 | 105.01 | 01:16.39 |
30 | 3,000 | 1189 | 60 | 29859 | 2957.09 | 22.6 | 90.51 | 02:12.90 |
40 | 4,000 | 1542 | 60 | 34707 | 3684.06 | 23.4 | 94.07 | 02:50.54 |
50 | 5,000 | 1785 | 61 | 49680 | 4891.46 | 24.4 | 98.03 | 03:24.54 |
平均 | 1114.2 | 60.4 | 27346 | 2740.27 | 24.14 | 96.89 |
クライアントPCパフォーマンス - api_find.php
同時使用ユーザ数 | 総リクエスト数 | Average[ms] | Min[ms] | Max[ms] | Std. Dev. | Throughput/sec | KB/sec | Time |
---|---|---|---|---|---|---|---|---|
10 | 1,000 | 474 | 89 | 1397 | 79.56 | 20.6 | 83.04 | 00:37.31 |
20 | 2,000 | 913 | 86 | 16601 | 1367.93 | 19.9 | 80.32 | 01:40.35 |
30 | 3,000 | 1520 | 83 | 30225 | 3118.3 | 18 | 72.63 | 02:46.41 |
40 | 4,000 | 2009 | 85 | 34210 | 3390.45 | 18.3 | 73.77 | 03:38.68 |
50 | 5,000 | 2488 | 84 | 50374 | 5114.6 | 18.2 | 73.63 | 04:33.85 |
平均 | 1480.8 | 85.4 | 26561.4 | 2614.17 | 19 | 76.68 |
こちらもサーバ側の負荷同様、FX.phpの方が全般的に応答速度が速いという結果となった。同時使用ユーザ数が多ければ多いほど、その差も顕著にあらわている。
登録処理と比較すると、サーバ・クライアント側ともにFX.phpの方が優れた結果となった。提供されている機能量がちがうため単純には比較できないものの、この差はなかなか無視できない値といえる。とくにWindowサーバのアプリケーションプールの設定によっては、著しい負荷がかかりつづけるとサービス中断・最悪IISごとクラッシュする事例もある。注意しておきたいところだ。