前回作成したレコードを編集する2つのPHPを使用し、動作パフォーマンスを比較する。

比較パターン・動作環境について

今回比較するのは「A. チューニングなし(修正IDの条件は外す)」「B. レスポンスレイアウトにフィールドがまったくないレイアウトを指定」の2パターン。編集で操作できるレコードはFileMakerスクリプトを併用しないかぎり、常に1レコード。この特性を活かし、編集後のレコード情報を取得しないことでスピードアップを図るというものだ。

Ajax処理でレコードの編集・保存をおこなう場合、返り値はFileMakerのエラーコード(errorCode)や対象レコード数(foundCount)だけで良いという場面がある。FileMakerでこのようなWebアプリケーションを実装している場合、わずかではあるがパフォーマンスの改善が望めるだろう。

FX.php / APIでのパフォーマンス測定

ここでの動作環境は次のとおり。

サーバPC (FileMaker Server)

  • OS: Mac OS X 10.6.3
  • CPU: 2GHz Intel Core 2 Duo
  • メモリ: 6G
  • FileMaker Server: 10.0.2.206

クライアントPC

  • OS: Ubuntu 9.10
  • CPU: 2GHz Intel Atom CPU Z550
  • メモリ: 2G
  • 負荷測定: Apache JMeter 2.3.4

クライアントPCからApache JMeterを使用し、前回作成したfx_edit.phpとapi_edut.phpにアクセス。応答速度やスループット値を計測する。

  • 同時使用ユーザ数(スレッド数): 10, 20, 30, 40, 50
  • リクエスト回数: 1回
  • ループ数: 100

1回のテストでfx_edit.phpとapi_edit.phpにそれぞれ1,000～5,000回、個別にアクセスして結果を解析。まずは環境Aの結果からだ。

クライアントPCパフォーマンス - fx_edit.php (環境A)

同時使用ユーザ数 総リクエスト数 Average[ms] Min[ms] Max[ms] Std. Dev. Throughput/sec KB/sec Time[ms]
10 1,000 265 43 628 77.35 36 23.67 00:27.75
20 2,000 494 40 12523 1178.47 34.7 22.94 00:57.59
30 3,000 689 40 23137 1950 36.9 24.26 01:21.22
40 4,000 1102 40 33562 3046.52 32 21.04 02:05.09
50 5,000 1178 40 35846 3139.98 36 23.67 02:18.66
  平均 745.6 40.6 21139.2 1878.46 35.12 23.12  

クライアントPCパフォーマンス - api_edit.php (環境A)

同時使用ユーザ数 総リクエスト数 Average[ms] Min[ms] Max[ms] Std. Dev. Throughput/sec KB/sec Time[ms]
10 1,000 494 152 805 63.51 19.8 13.53 00:50.32
20 2,000 985 77 1804 213.79 19.9 13.44 01:40.47
30 3,000 1378 78 25052 2417.4 19.7 13.32 02:32.26
40 4,000 2112 76 41153 3831.84 17.3 11.72 03:51.29
50 5,000 2351 77 48740 4778.89 19.1 12.94 04:21.91
  平均 1464 92 23510.8 2261.09 19.16 12.99  

環境A下でのFX.phpパフォーマンス結果

環境A下でのAPIパフォーマンス結果。検索同様、やはり同時ユーザ数が40以上の場合、パフォーマンスが落ちるようだ

レコード登録とおなじく、非常に快適に動作する。残念ながらAPIの場合、同時に使用するユーザが40を越えたあたりからパフォーマンスが落ちるようだ。

それでは続いて、環境Bでテストしてみよう。フィールドをまったく配置しないレイアウト「Null_Layout」を用意し、PHP側でレスポンスレイアウトを変更。JMeterで計測する。

環境B用のレイアウト「Null_Layout」を新規に作成。このレイアウトにはフィールドを一つも配置しないようにする

クライアントPCパフォーマンス - fx_edit.php (環境B)

同時使用ユーザ数 総リクエスト数 Average[ms] Min[ms] Max[ms] Std. Dev. Throughput/sec KB/sec Time[ms]
10 1,000 239 37 570 50.71 40.2 1.24 00:24.86
20 2,000 471 37 5356 222.85 40.5 1.34 00:49.36
30 3,000 614 36 19676 1937.8 40.5 1.33 01:14.05
40 4,000 1075 35 32451 2958.66 33.5 1.1 01:59.32
50 5,000 1079 35 39253 3284.13 39.1 1.26 02:07.74
  平均 695.6 36 19461.2 1690.83 38.76 1.25  

クライアントPCパフォーマンス - api_edit.php (環境B)

同時使用ユーザ数 総リクエスト数 Average[ms] Min[ms] Max[ms] Std. Dev. Throughput/sec KB/sec Time[ms]
10 1,000 446 72 950 72.92 21.9 0.61 00:45.64
20 2,000 893 64 1818 199.29 21.9 0.63 01:31.12
30 3,000 1232 76 26772 2597.19 21.5 0.62 02:19.73
40 4,000 1754 65 36098 3458.93 20.2 0.57 03:18.01
50 5,000 2077 75 48838 4414.53 21 0.61 03:58.45
  平均 1280.4 70.4 22895.2 2148.57 21.3 0.61  

FX.php/APIともにわずかながらパフォーマンスがよくなった。レコード編集時に変更をおこなうフィールド数が多ければ多いほど、この効果が表れる

環境Aと比較すると、わずかにパフォーマンスが改善された。レコード編集時に変更をおこなうフィールド数が多ければ多いほど、XMLのデータ量に差が出る。FileMaker Server - PHP間のデータ通信量やXML生成時の負荷が減り、スピードアップにつながるというわけだ。Ajaxを使用し、FileMakerのような「フォーカスが外れた瞬間に編集・保存がおこなわれる」Webアプリの場合、そこそこのパフォーマンスアップが見込めるだろう。