Lighttpd 1.5.0 を検証 → 現時点で移行は見送りだ

lighttpd-1.5.0 が stable バージョンに近づいてきたようです以前も紹介したとおり、1.4.x → 1.5.0 では多くの変更点があります。I/O 周りのパフォーマンス改善とか proxy 機能の多機能化が主な変更点かと。

Latest Pre-Release
 ・ lighttpd-1.5.0-r1691.tar.gz was release on 2007-02-23
Changes
 On the way from 1.4.x to 1.5.0 many things have been improved, changed and added and
 we try to keep track of them to make it easier for user to migrate their configuration.
 ・ IMPORTANT requires glib2-2.4.0 or higher
 ・ mod-fastcgi, mod-proxy and mod-scgi are replaced by mod-proxy-core

さて今 drk7.jp では Lighttpd 1.4.13 に勝手に patch を当てたものを使っていますが、Lighttpd 1.5 系が以前の公式ブログに掲載されていた情報通り 80% もスループットがあがるのであれば移行する価値ありと思い検証してみました。

- スポンサーリンク -

Lighttpd 1.4.13 vs 1.5.0-r1691 静的コンテンツ編

ちなみに、検証した 1.5.0 の conf ファイルは以下の設定がしてあります。

server.document-root = "/home/apache/drk7.jp/"
server.network-backend = "linux-sendfile"
server.event-handler = "linux-sysepoll"

さて、ベンチマーク結果。同時接続数 10 での検証。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /MT/images/MTWeather/100.gif /MT/images/MTWeather/100.gif
Document Length: 1320 bytes 1320 bytes
Concurrency Level: 10 10
Time taken for tests: 0.38515 seconds 0.58564 seconds
Complete requests: 100 100
Failed requests: 0 0
Write errors: 0 0
Total transferred: 155600 bytes 155500 bytes
HTML transferred: 132000 bytes 132000 bytes
Requests per second: 2596.39 [#/sec] (mean) 1707.53 [#/sec] (mean)
Time per request: 3.852 [ms] (mean) 5.856 [ms] (mean)
Time per request: 0.385 [ms]
(mean, across all concurrent requests)
0.586 [ms]
(mean, across all concurrent requests)
Transfer rate: 3920.55 [Kbytes/sec] received 2578.38 [Kbytes/sec] received

う〜ん・・・微妙。ちょっとした icon 程度の画像 = 1K byte 程度のファイルは 1.4.13 の方が速い。約 30 %のパフォーマンスダウン。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /index.html /index.html
Document Length: 34569 bytes 34569 bytes
Concurrency Level: 10 10
Time taken for tests: 0.43566 seconds 0.56059 seconds
Complete requests: 100 100
Failed requests: 0 0
Write errors: 0 0
Total transferred: 3480600 bytes 3480500 bytes
HTML transferred: 3456900 bytes 3456900 bytes
Requests per second: 2295.37 [#/sec] (mean) 1783.83 [#/sec] (mean)
Time per request: 4.357 [ms] (mean) 5.606 [ms] (mean)
Time per request: 0.436 [ms]
(mean, across all concurrent requests)
0.561 [ms]
(mean, across all concurrent requests)
Transfer rate: 78019.56 [Kbytes/sec] received 60614.71 [Kbytes/sec] received

う〜ん・・・微妙。drk7.jp のトップページ程度のコンテンツ = 30K byte 程度のファイルは 1.4.13 の方が速い。約 20 %のパフォーマンスダウン。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /pub/pound.tar.gz /pub/pound.tar.gz
Document Length: 706409 bytes 706409 bytes
Concurrency Level: 10 10
Time taken for tests: 0.647835 seconds 0.354660 seconds
Complete requests: 100 100
Failed requests: 0 0
Write errors: 0 0
Total transferred: 70665400 bytes 70665300 bytes
HTML transferred: 70640900 bytes 70640900 bytes
Requests per second: 154.36 [#/sec] (mean) 281.96 [#/sec] (mean)
Time per request: 64.784 [ms] (mean) 35.466 [ms] (mean)
Time per request: 6.478 [ms]
(mean, across all concurrent requests)
3.547 [ms]
(mean, across all concurrent requests)
Transfer rate: 106522.49 [Kbytes/sec] received 194577.90 [Kbytes/sec] received

ちょっとした圧縮ファイルのコンテンツ = 700K byte 程度のファイルは公式ブログの情報通り 80% のスループット改善となった。これが aio による大容量コンテンツのパフォーマンス改善と言うヤツなのでしょうか。

さて次に、同時接続数 100 での検証。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /MT/images/MTWeather/100.gif /MT/images/MTWeather/100.gif
Document Length: 1320 bytes 1320 bytes
Concurrency Level: 100 100
Time taken for tests: 0.440709 seconds 0.531953 seconds
Complete requests: 1000 1000
Failed requests: 0 0
Write errors: 0 0
Total transferred: 1556000 bytes 155500 bytes
HTML transferred: 1320000 bytes 132000 bytes
Requests per second: 2269.07 [#/sec] (mean) 1879.87 [#/sec] (mean)
Time per request: 44.071 [ms] (mean) 53.195 [ms] (mean)
Time per request: 0.441 [ms]
(mean, across all concurrent requests)
0.532 [ms]
(mean, across all concurrent requests)
Transfer rate: 3446.72 [Kbytes/sec] received 2853.64 [Kbytes/sec] received

う〜ん・・・やはり 1.4.13 の方が速い。約 20 %のパフォーマンスダウン。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /index.html /index.html
Document Length: 34569 bytes 34569 bytes
Concurrency Level: 100 100
Time taken for tests: 0.494032 seconds 0.637811 seconds
Complete requests: 1000 1000
Failed requests: 0 0
Write errors: 0 0
Total transferred: 34806000 bytes 34805000 bytes
HTML transferred: 34569000 bytes 34569000 bytes
Requests per second: 2024.16 [#/sec] (mean) 1567.86 [#/sec] (mean)
Time per request: 49.403 [ms] (mean) 63.781 [ms] (mean)
Time per request: 0.494 [ms]
(mean, across all concurrent requests)
0.638 [ms]
(mean, across all concurrent requests)
Transfer rate: 68801.21 [Kbytes/sec] received 53290.08 [Kbytes/sec] received

う〜ん・・・これまた 1.4.13 の方が速い。約 20 %のパフォーマンスダウン。

Server Software: lighttpd/1.4.13 lighttpd/1.5.0
Server Hostname: www.drk7.jp www.drk7.jp
Server Port: 80 80
Document Path: /pub/pound.tar.gz /pub/pound.tar.gz
Document Length: 706409 bytes 706409 bytes
Concurrency Level: 100 100
Time taken for tests: 3.255750 seconds 3.186863 seconds
Complete requests: 1000 1000
Failed requests: 0 0
Write errors: 0 0
Total transferred: 706654000 bytes 706653000 bytes
HTML transferred: 706409000 bytes 706409000 bytes
Requests per second: 307.15 [#/sec] (mean) 313.79 [#/sec] (mean)
Time per request: 325.575 [ms] (mean) 318.686 [ms] (mean)
Time per request: 3.256 [ms]
(mean, across all concurrent requests)
3.187 [ms]
(mean, across all concurrent requests)
Transfer rate: 211960.69 [Kbytes/sec] received 216542.10 [Kbytes/sec] received

ありゃりゃ・・・同時接続数が多いと 1.4.13 とほぼ同じパフォーマンスになってしまいました。あと、ベンチマークとっていて気が付いたのですが、1.5.0 は速度のばらつきが多いように感じます。まだまだ安定度からすると 1.4.x の方が良さそうですね。
glib2 のバージョンが 2.2.6 系の場合、threaded io ってオプションが使えるようです。こちらは未検証です。

Depending on the backend, your OS and the number of disks you might want to raise the two values, but keep in mind that you will get problems if you raise them too much. Performance will decrease again at a given point.
The performance of the different backends is: linux-aio-sendfile, posix-aio, gthread-aio, ...
On the way linux-aio-sendfile and posix-aio should behave better under high concurrent load now. They even got some stats:


まぁそれ以上に 1.5.0 への移行をためらわせたのは、mod_fastcgi の廃止による lighttpd.conf の変更です。1.4.13 までは、fastcgi の起動方法は2通りあって、lighttpd から起動する方法と spawn-fcgi を使って fastcgi プロセスを別途起動し、lighttpd から port や unix-domain socket を使って通信する方法があります。1.4.x 系は前者の方法をとることが多いと思います。利点は、lighttpd 側で fastcgi のステータスも監視可能でプロセスが死亡すると自動的に再起動とかしてくれます。

逆に後者の方法は前者の方法に比べてパフォーマンスの点で分があるようです。その代わり spawn-fcgi で fastcgi プロセスを起動した後はそのプロセスの監視は別途行う必要があります。

で、何が言いたいかというと、1.5.0 系は後者の spawn-fcgi での方法のみになったと言うこと。今まで lighttpd 経由で fastcgi を起動していたので、conf とかそのまま使えない。っていうか、

fastcgi.server = ()

ってパラメータは廃止されています。むむむ・・・これは頂けないかも。
というか、mod-proxy-core はその名の通り proxy のお仕事に専念するわけです。それに統合された mod_proxy_backend_fastcgi もその名の通り、fastcgi プロセスへの proxy としての機能が実装してあるだけなんですね。

ってことで、fastcgi 周りは未検証。単に spawn-fcgi で起動して云々するのが面倒くさいだけなんですけど・・・まぁ〜ウチのサイトの場合、細かい画像の配信とか Amazon Search でやっているので、1.4.13 の方が当面よさげってのは十分検証できた気がします。

- スポンサーリンク -