表題の通りです。現在自作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ってほんとすごいな