テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(akashic report) GET性能評価(abによる並行アクセス)

1.0.0-RC3のタスクとしてabを使った性能評価をするとなっているので, とりあえずやってみた.

使ったのは自宅のマシンで,

  • CPU: i7-3770 (4cores/8threads)
  • ディスク: なんかのSSD // 今回の実験ではあんまり関係ない

3種類(1, 4K, 1Mバイト)のファイルを置いて, それをab -cの値を1,2,4,8,16と変化させて読みまくる実験. 家のLANがしょぼいので, クライアントとサーバは同一マシン内で実行することにした.

今回の結論としては, アカストはきちんとマルチコアを活かすが, それが線形スケールするかは実験結果からは判断出来ない. よりCPUが多い環境でやるなりする. c1でも2ms/1reqで駆け抜けているので, 十分とみて, これ以上の最適化はとりあえずしない.

f:id:akiradeveloper529:20160501101455p:plain (青:1, 赤: 4K, 黃: 1M)
(エクセルスクショギョム)

グラフを見て分かることは:

  1. ファイルが大きくなるほど, cを上げた時の落ちが小さい
  2. どのケースもc4でぱたっと止まる
  3. 1Mのケースではc4以降もやや伸びする

私の考察は:

  1. IOが小さい場合は1000req/secまで伸びるので, 1MBの場合も, アカスト自体の能力としては1000req/secまで伸びるはずである. 従って, ハードウェアが足かせになってる.
  2. 8スレッドをクライアントとサーバで食い合ってる. だからc4までしか伸びない. 1Mの時伸びるのはIOが長くなるので, クライアントがCPUを明け渡した.

今後としては:

  1. でかいファイルを読めばネットワークがボトルネックになってくれるから, アカストの最適化は意味なし. (ちなみに, 1MBの場合はloopback TCPで600MB/sec程度出てる)
  2. 従ってやるならファイルが小さい時の性能を上げることだが, 今でもc1で2ms/req程度なので, これ以上どうやって最適化するのか(いやしない)
  3. より低速なバックエンド(例: 分散ファイルシステム)でやった場合に, バックエンドとのやりとりも重くなるため, これが挙動にどう影響するかは興味がある. それらのIOでブロッキングした時にCPUを明け渡すことになるが, この時にきちんと動いてくれるかは今回の実験からはわからない.