Mojoの遅さはたいした問題じゃありません

わかっている人にとってはごく当たり前の話ですが、あらためて明記しておきましょう。

最近ここで取り上げたMojoが、見ようによっては存外遅いというベンチマークが公開されました。また、MojoのライバルともいえるHTTP::Engineとの性能比較も紹介されています。

その結果については、とやかく申しますまい。CGIとしてのfairさはさておき、（mod_phpなどの）常駐モジュールと比べて（perlが、ではなく）CGIがあきらかに桁ひとつ遅いというのは、十年も前からわかっていたこと。いかに小手先のテクニックを駆使したところで、その事実が覆ることはこの先もないと言ってよいでしょう。

でも、MojoやHTTP::Engineにとって、大事なのは、そういうことではないはずですよね？

従来のCGI.pm（あるいは、より速いCGI::Simple)を使った解は、いざユーザが増えてより速いFastCGI、あるいは（mod_phpと同等以上の性能が出る）mod_perlに移行するときに――paramなどのAPIはかなりの部分踏襲できるとはいえ――場合によってはほとんど全面的といっていいほどの書き直しをする必要がありました。

CGI::Appのようなラッパをかませた場合はまだましでしたが、それでもそのアプリに対してユニットテストを実行しようと思うと、当初はやはりサーバの準備などの点でやや構えるところがあったように思います。

HTTP::EngineのベースになっているCatalystのエンジンはそういう問題をかなりよく解決してくれました。依存モジュールが多いのでその辺のレンタルサーバにポンとインストールできるようなものではありませんが、Catalystの場合、公開領域にあるレンタルサーバでテストしなくても、たとえばイントラネットのなかにPARで固めたものをおいてやれば顧客向けのデモ／テストくらいは十分こなせます。そもそも簡単な動作確認テストであれば、いちいちサーバを立ち上げてページを開いていかなくても、内部でテスト用のリクエストを発行して結果確認できますし、そこで動作確認できたら、コードはまったく変えずに本番サーバに持っていって、mod_perlなりFastCGIなりで動作させられるようになっています。

Mojoも同じ。まだ開発途上だけあってmod_perlの解は存在していませんが、おそらく近い将来、じれただれかがそういうモジュールを用意することでしょう。なにしろCatalyst(や、それを踏襲したHTTP::Engine）あるいはCGI::Appにはすでにそういうmod_perl対応モジュールがあるのですから、Mojo用に移植することくらい、たいした手間にはならないはずです。そうして、同じようにレンタルサーバなり、標準装備のスタンドアロンサーバなりで動作確認したら、本番環境に持っていく、というのが実際の開発の流れになるはずです。

たしかにFastCGIやmod_perlに持っていったところで、場合によってはあまり速くならないかもしれませんし、単純な表示の速さでは素のPHPには勝てないかもしれませんが、速さというのはそんなところでばかりはかれるものではありません。リリースのたびに人海戦術ですべてのページのXSSやらなにやらをチェックしていくのと、サーバを通さず、直接アプリ本体をたたいてXSSなどのチェックをしていくのと、どちらが速いか。あるいは事前に大量のキャッシュを用意したくなったとき、どうか。そんな、ベンチマークスクリプトでははかりがたい要素だって、大事なポイントなのではないかしら。

低予算の受託開発などで本番サーバと同等の検証サーバは借りられないとかいう事情があるときでもレンタルサーバ経由で動作確認してもらいやすくなっているという意味で、Mojoのインストールのしやすさはひとつの福音になっているとは思いますが、そういう場で、レスポンスの速さはあまり問題にはなりませんよね？

本質でないところのベンチマークに惑わされないようにしてくださいまし。