| « MySQLはバグが少ない--ソースコードの分析で判明 | SQLiteサイトのベンチマークは間違い!? 少なくとも古すぎ » |
PukiWiki vs Hiki
具体的な数値はさておきkazuhikoさんから「PukiWikiよりHikiの方が3倍くらい速い!」と聞きました。実際、モジュール版PHPとmod_ruby版Rubyで比較するとそれくらいの差が出るようです。
PukiWikiが遅いのは生成したページデータのキャッシュをほとんど全く行っていない事が原因と思います。Hikiの作りは良く知らないのですが、PukiWikiより多くキャッシュをしているようです。
print('ABCDEFG');
と言う簡単なスクリプトをPHP, mod_rubyで実行し、abで比較するとPHPの方が3倍くらい速かったのでmod_rubyはリクエストの初期化にもう少し改善できる余地があるようです。個人的にはPukiWikiの速度に全く不満は無いのですがアクセス数が多いサイト様にもう少し性能アップしても良いのかも、と思いました。
そこでwikipediaなどで使われているMediaWikiを試しにインストールしてabでベンチマークしてみました。結果は悲惨なことにPukiWikiの半分以下の性能でした... MediaWikiはMySQLにデータを保存しているのでオーバーヘッドが大きいとは言えますが、それにしても2リクエスト/秒弱(AthlonXP2500+)とは遅すぎです。
最後にmod_rubyはスクリプトをキャッシュしている(?)らしいのでphp-eacceleratorをインストールするとPukiWikiの速度は2倍くらい(10リクエスト/秒)になりました。それでもHiki+mod_rubyの方が50%くらい速い事になります。
注意:いい加減なベンチマークなのであまり具体的な数値は書きませんが、イメージは解かると思います。コメント歓迎します。
2 コメント
多くあると、特にメモリ絡みで他のmod_*よりも性能的には不利になるような感じが
しています(便利さ、という観点では有利になる事もあると思います)。
・リクエスト開始時のメモリを始めとする初期化処理や、その他諸々の処理
(その他諸々の処理例:スーパーグローバル配列の生成とか)
・リクエスト終了時のメモリの開放絡みや後始末的な処理
「PHP_RINIT」や「PHP_RSHUTDOWN」辺りです。
大垣さんは、そんな事を感じた事はありませんか?
後は、内部的に色んな事が汎化しすぎて重くなってるとか。。。
話はちょっとズレますが、mod_perlは(特に指定しない限り)変数もキャッシュ
されるので、キャッシュの有効利用という点ではカナリの性能差が出ると予想
しますが、逆に悲惨な目にあう事もあったりしますね。
この点に関しては、今のPHPの仕様は好きです。。。というより、変数がクリア
されないのは怖いです。
この辺り、mod_rubyの仕様は不明です。。。出直してきます。(^^;
自分がよくハマるのは(下位|上位)互換性を考慮しすぎて、スクリプトでダラダラ
書いてしまう部分がボトル・ネックになったりします。
特に仕様変更が激しい関数の利用は控えています。。。
(他のmod_*は素人同然なので)認識が間違っていたら指摘して頂ければ幸いです。
色んな意味を含めて、PHP5.1には期待ですかねぇ。
大垣さんの指摘通り、mod_rubyやmod_perlと比べて(素の)mod_phpはスクリプトを
キャッシュしないので、そういう意味では公平ではないなぁ。。。と思います。
http://www.php.gr.jp/
> 通常のCGIとして使用できますが、PHPモジュールをApacheサーバーに組み込む
> ことにより、 Perl/CGIと比較して処理速度の高速化、サーバー負荷の低減が
> 可能です。
と、mod_phpとPerl/CGIを比べようとしているのと同じくらい。(^^;
この手の話をするのは新たな火種をおこしそうで、ちょっと怖いですが、
なんとなく大垣さんと話したかった気分になって。。。(w
ただ、最近は、スクリプト言語同士で優劣を競うよりも、
http://www.rubycolor.org/maki/d/200412c.html#29_t2
http://www.rubycolor.org/maki/d/200412c.html#30_t2
にあるような「LL VS 非LL」に興味があったります。
すみません。そこより、次の部分の気になりました。
ところが。PHPは、たぶん腐った仕様でも突っ込むんですよ。それがWebアプリケーション開発に「便利」であれば。もちろんそんな発言をPHP開発者の方から聞いたわけではないのですが、そんな気がすごーくするのです。
何故気になるか、というとその通りだったりするからです。技術的に非常に非効率だったり意味不明だったりする変更に意見したりToDoリストに書かれている関数名の統一を行おうとしても「Objection!」と言う方が...結局見通しの良くない(腐った仕様)が入って行ったり、残ったりするのを何度も目撃したり当事者だったりしました。
と書くと、じゃあPHP4よりもオブジェクト指向を強化したと言われるPHP5の方がずっとよいと考えているように思われるかもしれませんが、実はあんまりそう思っていません。あれは変にJavaを意識しすぎているんじゃないでしょうか。そのため、Javaに機能を導入しようとするあまり、 PHPのLLとしての良さを削ろうとしているように見えてしまって、ちょっと警戒しています。むしろ、オブジェクト指向と直接関係がない、例外の強化やリフレクションの強化の方を歓迎しています。
PHP4のオブジェクトモデルはクラスライブラリの設計者から見ると、全然使えない、とまでも言わなくても、OOPサポート機能が少なすぎた。と言えると思います。
個人的にはPHPを選択している最大の理由は「エラー処理」ですが、私の様な使い方をしている方は少数なのか結構壊れている部分もあります。(これもいわゆる「腐った仕様」が入ってしまったためかな..)
まあ、いろいろ不満もあるのですがやはりPHPは速く/安く/安定したWebアプリケーション
作るには非常に便利と思います。「速く/安く/安定した」を達成するためには慣れも必要ですがJava/C#に慣れるよりPHPの方がかなり速く慣れることが出来ると思います。
もし複雑なビジネスロジックがありLLで実装したWebアプリケーションに組み込む事が難しい場合、どこかのサーバで実行しCORBA(PHPでも使えます)、XMLRPC、WDDX、SOAPなんでもよいのでこれらを使えば良い、と考えています。基本的にはWebアプリケーションはフォーム処理(ページ処理等も含む)とユーザ管理(セキュリティ確保なども含む)だけを行えば良いと思っています。私はこう考えているのでLL以外の言語でWebアプリケーションを作る必要性を感じません。