makotan _at_ gmail dot com

HTTPベンチマークを見ながら思うこと

注:今年感じた個人的感想です

HTTPな各種サーバを大きく分けると


純粋な非同期サーバの開発言語として有名なのはGoとNodeの2つ
色んなベンチマークで優秀な結果を残してるので最近の高トラフィックな環境でもよく使われてる感じ
特徴的なのはランタイムも非同期がベースに構成されててCPUを生かし切る為に生まれてるような言語とランタイムになってる
特にコネクション数が増えたときの安定性は抜群


純粋なブロッキングサーバは最近減ってきたけど、まだ多少残ってる感じ
各種ベンチマークでボロクソに比較されて悲しい感じになる
問題はソケットの処理のためにスレッドを立てる必要があるのでコネクション数=スレッド数になってC10K問題にキッチリぶち当たる
ただし、コネクションが少ない状態でのレスポンスの安定性は抜群だし、プログラムが凄く楽


非同期とブロッキングのハイブリッド
新しめのTomcatとか含めて純粋な非同期の前の主流な感じ
ソケットの処理そのものは非同期でやっておいて、メインの処理はブロッキングで書くみたいな感じ
特徴もやっぱり間くらいw
同時処理数+コネクション管理用スレッド=スレッド数になるので実はC10K問題はそんなに起きない


HTTPなベンチマークの特徴

  • 同時コネクション数をどのくらい処理出来るのかをひたすら試す
  • コネクションを張ってからレスポンスを受けるまでの時間の測定
  • コネクションを再利用しつつ、レスポンスを受けるまでの時間の測定
  • コネクションの再利用無しでレスポンスを受けるまでの時間の測定


この4種類くらいがあって、同時コネクション数が優秀な場合最初の1個しかやってないパターンが多い気がした
実際には実用的なコネクション数でレスポンスの良さを測定する必要があると思ってる
というのは、HTTPサーバの場合に限って言えば1台のマシンでC10Kを処理するWebサーバを作る事は世の中的に滅多に無くて、複数台使って秒間で1000reqの処理が安定して出来ていれば良いことの方が圧倒的に多いから。(CDNに逃がせる画像とかを除いて1000req/sは相当大きめの数値だと思ってる)


絶対的なコネクション数を試すベンチマークより、適当な数のコネクション数でどの程度のパフォーマンスが出るかの方が結構大事な気がする


そんなことを思った2017年もあと少し
今年は紅と白どっちが勝つんでしょう・・・