論文の執筆や発表の準備で最新のmrubyに追随できていなかったのですが、ようやくmod_mrubyとngx_mrubyを最新版のmrubyに対応させました。対応した項目は以下となります。これでmrubyの最新版でも動くようになりました。
- mrb_stateが持っていたirepテーブルの削除に対応（バイトコードのGC化）
- symbol関連のAPI変更に対応
- ARENAの持ち方を修正
パフォーマンス比較をするには良いタイミングなので、最新版のmod_mrubyとngx_mrubyのパフォーマンスを計測しました。
最新のパフォーマンス比較
計測方法はいつも通りシンプルなものなので、「この条件だと大体こういう差がでる」という意味での参考情報として見て頂けたらと思います。
テスト環境や条件は大体いつもと同様、
- サーバはXeon X5355 2.66GHz 4コア、メモリ8GB、NIC1Gbps
- Apache2.4.6のevent MPMでプロセスの破棄が生じないように設定（設定はこの辺り）
- nginx1.4.4のworker_processes 4
- 今回は127.0.0.1向けにabで同時接続数100総接続数10万keepalive有で測定
- 単純なhello world文字列のレスポンスデータを生成
- mod_mrubyとngx_mrubyはcacheオプション付きも測定
- mod_helloという従来のC言語実装Apacheモジュールを用意して測定
- apache httpdとnginxでindex.htmlの静的コンテンツに対しても測定
となります。このような条件だと、以下のような結果になりました。
やはり、軽量な処理はnginx自体の性能と比例して、ngx_mrubyのcacheオプションが最も早く、次いでnginxの静的コンテンツであるindex.html（hello worldをtext/plainで返す）、ngx_mrubyの都度コンパイル方式になりました。
また、Apacheにおいては、C言語で実装したmod_hello（任意のURLにアクセスがあったらhello worldをレスポンスデータとして返す）が最も早く、それと同程度の性能で静的コンテンツ、mod_mrubyのcacheオプション、mod_mrubyの都度コンパイル方式という順になりました。
ざっと見た感じでは、このようなベンチマークの条件においては、mod_mrubyやngx_mrubyのcacheオプションはApacheやnginxの性能に対してほとんどボトルネックになっていないように思えます。
まとめ
現時点での上記の限定的なベンチマーク条件では、このような結果になりました。今後は、もっと実用的な使い方、例えばリバースプロキシや外部データストアにアクセスなどの実装でパフォーマンス比較をしていきたいと思っています。