HTTP
weighttp

weighttpを使ってサーバー速度を測ってみよう!

表題の通りです。現在自作OSSが使い物になるか試すためにlighttpdのマルチスレッド化にトライしているのですが、それがやっとまともな性能測定が出来るレベルまで動作するようになったので測定してみました。

準備~weightのインストール

構築した環境はUbuntu18.04です。

1 . 事前準備その1, ソースコードダウンロード
以下からダウンロードします。
https://github.com/lighttpd/weighttp

2 . libevのインストール

sudo apt install libev-dev

3 . コンパイル、インストール
ソースを展開して以下を実行します。

./autogen.sh
./configure
make
make install

インストールのデフォルトパスは/usr/localになります。

使ってみる

使い方は以下です。

weighttp -n リクエスト数 -c 同時接続クライアント -t クライアントが使用するスレッド数 -k(キープアライブの場合) localhost/index.html

例えば1クライアントから100,000コネクションを試すなら以下のような感じです。
$ weighttp -n 100000 -c 1 -t 1 -k localhost

出力はこのように、処理時間の他にstatus code, failedパケットの数等が確認できます。

$ weighttp -n 100000 -c 1 -t 1 -k  localhost/index.html
weighttp 0.4 - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 1 concurrent requests, 100000 total requests
progress:  10% done
progress:  20% done
progress:  30% done
progress:  40% done
progress:  50% done
progress:  60% done
progress:  70% done
progress:  80% done
progress:  90% done
progress: 100% done

finished in 9 sec, 728 millisec and 61 microsec, 10279 req/s, 36050 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 359118810 bytes total, 23018810 bytes http, 336100000 bytes data

比較してみる

いくつかパターンを変えてlighttpd 1.4.49とマルチスレッド化lighttpdの速度比較をしてみました。

比較結果

index.htmlにアクセスする速度 (100,000リクエスト)

パターン lighttpd 1.4.49 速度 リクエスト/sec マルチスレッド化速度 リクエスト/sec
1 client, 1 thread 8.440sec 11847 9.728sec 10279
4 client, 1 thread 1.728sec 57862 2.609sec 38327
4 client, 4 thread 2.284sec 43769 2.717sec 36797
100 client, 4 thread 1.608sec 62185 1.725sec 57952
500 client, 4 thread 1.720sec 58126 2.192sec 45604
1000 client, 4 thread 1.893sec 52823 1.463sec 68311

純粋な1回1回のリクエストはlighttpd 1.4.49の方が格段に速いですが、クライアント数が増えると勝負できるくらいのスピードが出ています。
実際にprogressの進みを見てる感じ、lighttpd 1.4.49は各コネクションの応答を同じ速度で返しているのに対し、マルチスレッドの方はドドドっと返してちょっと止まってといった動作をしていたので、weightを実行するPCを分ければもう少しいい結果が出るかもしれません。

また、今回の修正でいい影響が出ていそうな重い処理として、cgiの比較もしてみました。
cgiにアクセスする速度 (10リクエスト, リクエスト/secは省略)

パターン lighttpd 1.4.49 速度 マルチスレッド化速度
1 client, 1 thread 60.707sec 60.129sec
4 client, 4 thread 18.243sec 18.045sec
10 client, 4 thread 6.107sec 6.113sec

う~ん、変わらん(笑) でもpythonコードを利用してコード自体はすっきり出来たので、速度がトントンで割と満足です。

…というか先々月の自分は、この時点でlighttpdに速度はトントンか勝てるとか言ってたんですよね。実際はいじればいじるほど色々と工夫をしないといけないことがわかり、泣きそうでした笑
おかげでいいthreadpoolのライブラリが出来ましたが。

ちなみに1000でやめたのも私がいじったマルチスレッドlighttpdがこれ以上は安定して動作しないからです。
ここから先のバグつぶしは本質から離れていくのでやる気ないですが(-_-;)

余談:メモリ比較

ついでにメモリ使用量の比較もしてみました。

モジュール メモリ使用量
lighttpd 1.4.49 32MByte
マルチスレッド化lighttpd 561MByte

…ま、まあライブラリ使用感確認の為に接続可能なコネクション分のメモリ取ってたり、スレッドのスタックサイズ8つ立ち上げたり、メモリについては気にせず作ってますからこれくらい許容範囲じゃないですかね(震え)
軽量 && 高速を実現することの難しさを感じます。

世の中で使われてるOSSってほんとすごいな