私がインタビューアーと執筆を担当させて頂いたRasmusさんへのインタビュー記事は好評だったようです。
http://gihyo.jp/news/interview/2010/rasmus
この記事の中で「美しいツールは美しい問題を解決するためには非常に効果的かも知れませんが，多くの場合は必要がありません。さまざまなルールを作り，フレームワークを使い，モデルやビューを使って解決できない問題があるのです。」の部分は解説が無いと理解できないかも知れません。Rasmusさんなら私と同じようにこう思っているハズという補足なので外している可能性もありますが、この部分の意図を補足します。
Rasmusさんもパフォーマンスについてはかなりうるさい方です。RasmusさんがYahooの為に働き出した頃「statシステムコールが多すぎて遅くなる」と文句を言っていた事を良く覚えています。私が普段常用しているLinuxの場合、statシステムコールはカーネルレベルでキャッシュ（ディレクトリエントリがキャッシュ）されていました。ディレクトリに書き込まなければ非常に速く処理できます。Linuxでは15年くらい前には実装済みだったと思いますが、FreeBSDは比較的最近になるまでディレクトリエントリのキャッシングは実装されていませんでした。これがどのくらいパフォーマンスに影響を及ぼすか、パフォーマンスにうるさい方なら良くご存知だと思います。
PHPのinclude/require文は現在のパスを/（ルート）から検証します。つまり、/some/dir/under/very/deep/dir/in/the/system というディレクトリのファイルをインクルードすると10回のstatシステムコールが呼ばれる事になります。この問題を解決するためにRasmusさんはPHPの内部でキャッシュする仕組みを実装しました。
開発者に優しい高機能な開発環境と性能はトレードオフの関係がある場合が多いです。非常に高いパフォーマンスを求められるシステムでは様々な「無駄」を省く必要があります。F1に乗用車のような装備が必要とされていないのと同じです。開発者に優しいフレームワークは乗り心地のよい市販乗用車のような物です。様々な安全装備や快適性の為の機能が提供されています。
Webアプリはステートレスであるため、一つ一つの処理は小さく完結する物になっています。セッション管理で状態を管理しているとは言っても「リクエストがあったらレスポンスを返す」ただそれだけを行うのがWebアプリです。「リクエスト」に対して「レスポンス」を返すだけが仕事のWebアプリに、モデルやビューは無用とは言いませんが、高性能なWebアプリを作るには「無駄」なのです。最近のPCなら単純なリクエストを受け付けて、レスポンスを返すだけなら毎秒1万リクエストでも処理できますが、モデルやビューと言った仕組みを使うだけで桁違いに遅くなります。大規模なシステムであれば多少の開発コストの増加はサーバの効率的な利用で簡単にペイできます。
Web企業の多くが開発コスト、開発速度、安全性、メンテナンス性、性能を天秤に掛けて様々なアプローチで問題を解決しています。開発者を十分に教育できる企業であるなら、一般的なWebアプリフレームワークを使う意味はあまり多くありません。一般的なWebフレームワークと開発環境は開発コストとメンテナンス性に重点を置いているからです。Googleで一番多いプロジェクトはC++のプロジェクトだそうです。なぜC++のプロジェクトが多いのか？その理由は聞く必要もないでしょう。
PHPに限った事ではありませんがMVCフレームワークを使わないクイック、ダーティーな方法で実装すれば10倍、20倍、100 倍速くなる。このような場合はどちらを選択すべきなのか？は状況によって違います。1台のサーバでお釣りがくるようなホームページと、最適化していれば1000台のサーバで済むサービスに1万台、2万台、10万台のサーバを導入する必要があるサービスとでは必要とされる条件がまったく異なります。
クライアントサイドでの処理も増え複雑化してきているWebアプリですが、サーバ側だけ見ると15年前とあまり変わりません。
リクエストが来たら、レスポンスを返す
これがWebアプリのサーバサイドの仕事です。この簡単な仕事を”超”効率良くこなすにはどうすべきか？MVCフレームワークで綺麗にモデル化したアプリケーションが正解ではない環境がリアルな世界にはあるということです。
