はじめに
最近lighttpdについて色々まとめていましたが、それは私がずっとlighttpdに対して持っていた疑問の深堀をしたかったからです。
なんでシングルスレッドなのに速いの？
また、私は今作成したOSS design_pattern_for_cのサンプルコード作成対象として適切な相手を探していました。
作成したOSSはライブラリパッケージなので、目的のちゃんとしたシステムで一発サンプルを作らないと、面白いパッケージになっているのかが正直見えてこないんですよね。
そんな私の2つの思いを解決する手段として思いついたのがこれ。
design_pattern_for_cを利用して、lighttpdをマルチスレッド化してみよう！
この記事では、まずはやろうとしていることを公開して逃げ道をなくし、今後、作業進捗とともにわかったこと、有益だと感じたことを記事内で更新していこうと思っています。
なので今はなんの結果も詰まっていないポエムみたいなものです。
実施コードはこちら
基本方針
目的
- lighttpdをマルチスレッド化して比較測定を行う
- lighttpdの修正を通して、高速・軽量を実現している工夫を探る。
- design_pattern_for_cがライブラリパッケージOSSとして有用になるよう、issueを沢山洗い出す。
成果物
サンプルを2～3段階に分けて作成します。条件は以下:
-
プラグインAPI, よく利用されるAPIの動作in/outは変えず、lighttpd向けに実装したプラグインはそのまま利用できるようにする。
⇒そうしないと比較にならないため。今まで作ったcgi/プラグインの利用で比較。 -
比較測定結果を提示する。
- 速度 -- HTTPはweighttpを、HTTPSはSSLyze辺りの複数実行で試してみる。その他いい案があれば更新。
- 軽さ -- 上記実行中のCPU使用率、メモリ使用量を比較します。
-
比較対象
- lighttpd 1.4.49
-
保証動作環境
- Ubuntu 18.04 Desktop
構想
今のところ、このような方針で作業を考えています。
-
第一弾
- design_pattern_for_cのStateMachineを利用してセッションごとにマルチスレッド化 ～ シングルスレッドとの速度比較の為
-
第二弾
- ヘッダー情報のストレージ: HTTP/2のように出来るだけ作成したヘッダー情報を流用して速度向上を目指す。 ～ Flyweight(もしくは未作成のPrototype)の利用
- fdeventは活かすが、ソケットの扱いが変わるはずなのでイベントの制御をPublisherを利用して置き換える。 ～ PUblisher使用感確認も兼ねて
- 必要に応じてdesign_pattern_for_c側にFDを利用したライブラリAPIを追加
- design_pattern_for_cのchain_of_responsibilityを利用して、プラグイン処理の置き換え ～ chain_of_responsibility使用感確認も兼ねて
- その他今の構成に合った形で無駄なデータを削除
結果予想
-
第一弾での比較
- 速度はトントンか少しだけ向上、後は惨敗
-
第二弾での比較
- 速度はもう少しだけ向上、後は惜敗
-
結論予想
- YLS(やっぱりlighttpdはすごい！)
作業中に気付いたlighttpdの凄い所があれば、別途まとめて行きたいと思います。
進捗
2018/06/16
第一弾 F5連打に何とか耐えられるレベルまでは作成出来たが、weighttpで計測できるレベルに至らず。lockだらけになったので返って遅くなりそうな気配
ちなみに
別に投稿者はlighttpdに不満があってリファクタしてやろう！って思ったわけではないです。
実際HTTP仕様の更新や脆弱性への対応も早いですし、導入も簡単だし。(プラグイン周りでは不満もありますが、どんなツールにも多少の不満はあるものですよね？)
ただこんな感じに色々な要素が積み重なっただけで、悪意はないのであしからず。
- ライブラリを適用してみる大き目のシステムとしてHTTPサーバーは適切だった
- 純粋にlighttpdがどう強力なサーバーとして動作しているかが気になっていた
- 仕事で何度か中をデバッグしたことがあり、多少は中身を把握していた