新しいベンチャー企業考えた

嫌よ嫌よと言いつつも世に流布するbuzz wordに耳を傾けずにはおれない私だった.Nginxからのフォークで「受け付ける設定ファイルの書式は完全Apache互換」というソフトをどうにかマネタイズ*1する会社を立ち上げたらがっぽり儲かるかな? mod_{perl,python,php,ruby} 動くようにしてdrop-in replacementに...
ここで mod_* への「互換対応」がNginxの良さをどの程度殺すか,これが問題となるだろう.スレッドごとに mod_* 内のinterpreter contextを生成するかどうか分けられないのかな? (Codeセグメントはスレッド間で共有されるよね?) ApacheもNginxもパスごとに設定をenable/disableする機能はある程度共通に有する.そのセマンティクスを保ったまま一部のスレッドはAPサーバとして mod_* からインタプリタを生成してコントローラで一部のパス (/cgi-bin/ etc.) に張り付けて(I/O待ちあるから,1スレッドに2,3個までinterpreter contextのプールを作ってもいいかも?),残りのスレッドは「Nginxらしく」非同期イベントループを生かして /static/ etc. の対応に専従させる. ... ってのでどう? うーん,実は自分ではほとんど経験無いのでどう動いてるかよく知らないのだが.
現状の常套手段はNginxの裏で 8080/TCPApache + mod_* に丸投げるようだが,十分実用的だけど理想形かと言われると疑問符が付くよね? 疎結合の方がフェイルオーバしやすいというのは分かるが,密結合の方がハードウェアコスト当たりのパフォーマンス高いのも事実で...
まぁあれか, mod_php (Zend engine) のマルチスレッド対応とか自分で確かめて見ていかないといけんね... (幸い PHPは未体験.) ふひひ... 嫌あぁぁ
追記: 私からすればすげーいいとこ突いてる質問なのに,なんでArsから「きょう ぼくは あたらしいうぇぶさーばの えんじんいくすを つかってみました。はやかったです。」なんぞ貼られただけで放置されてんの...? やっぱみんな分かって使ってる訳じゃないんじゃね?

*1:結局「導入支援/コンサルティング」と称して人月商売になったら自分は関わりたくないが... アイディア顧問料だけいただければうれしいです!