ここにビギナー向けの記事がある。
単純にサーバーサイドの処理を突っ込むと、ドコかで長い処理があれば、他のリクエストは待ちぼうけになるようだ。つまり、Windows 3.xのようなノンプリエンティブな作りになっているのだ。
apacheみたいリクエストを一個づつスレッド化すれば、サーバーサイドの処理はリクエストごとに独立しソースに書いた通りに綺麗に動くハズだが、同時接続が５００くらいになる（つまり同時に存在するスレッドが５００を越えると）と、多数のHDDアクセスやらDBアクセスが同時処理となり大混乱になるのは容易に予想でき、ノタノタになるのは目に浮かぶ。apacheを使うなら同時接続数が際限なく増えないようにサーバーサイドの処理は手短に短時間で終わるように作らないといけない。
TomCatはapacheの様にプリエンティブでマルチスレッドだから同時接続数が増えればやっぱりノタノタになるだろう。
一方、ノンプリエンティブなら手短な処理だったら、他の要求はそのままちょっと待たておいて、そのまま処理を実行すれば、リクエストは順次処理されるのでHDDアクセスやらDBアクセスは同時接続するのは１セッションのみのハズで、結果として乱雑なNASや他のサーバーへのアクセスが減り全体としてのパフォーマンスが上がる可能性が出てくる。
仮に同時接続１００ぐらいまでなら十分な性能が発揮できる高価なＤＢサーバーだったら、node server.js をポートを別けて１００プロセス実行し、オートバランサーでリクエストを公平にばらまけば、高価なＤＢサーバーの性能を１００％発揮できるだろう。
そして、本当に重い処理（膨大なレコードを参照する年次処理とか、１０００ページを越えるＰＤＦファイル作成など）の場合だけ、子プロセスを作り、できればサーバーも別にすればシステムの過負荷時のリスクも相当減ってくる訳だ。
ま、今あるNode.jsをベースにした色んなパッケージがそのように出来ているのかは判らないが、泥臭いチューニングをそのままベタ書きできそうで心強い。
apacheのことを悪く書いてしまった様な気もするが、ＷＥＢのフロントエンド、そしてオートバランサーとしてのapacheは使い道がある。ＴｏｍＣａｔだって裏側で重い処理専用のアプリケーション・サーバーとして利用する分には十分に使えるだろう。
そんな訳で、その中にＰＨＰには不向きで、TOMCATには荷が重すぎる様なサービスをＮｏｄｅ.jsで作っていくのは悪いアイデアではない気がする。
多分、一番良くないのは、Node.jsがあれば、apacheもPHPもTomCatも要らないとか言い出すコトだろう。
まずapacheのゴチャゴチャな設定ファイルをNode.jsで作ったポータル用に解析しコンバータを作らないといけないし、本当に要求仕様を満たしているのかわからない大量のPHPやJavaServletのソースを延々とｊｓに書き直してみたら高価なサーバーだったからコレでも動いていたのか？な、つまらない結果を見ることになるだろう。
※このBlog鯖のapacheの設定ですら結構ゴチャっているだ。
所詮jsの速度が数倍から数＋倍になってもネイティブなコードとの差は絶対的である。
さらに簡単なコードだからこそ、ＧＣの性能も十分に出ると考えていいだろう。重厚長大なjsファイルなぞ起動するだけでも使用メモリが恐ろしいコトになる気がする。
例えば、身近な例として、
クライアントのＩＤＥとしては普通なフルセットのEclipse IDEをそのまんまサーバーサイドなNode.jsに移植したらどうなるだろう？
プロジェクト全員が使っているＩＤＥであるから、プラグインの入れ替えは深夜作業になるだろう。
どう考えても面倒でも各自のパソコンにＩＤＥを入れて試行錯誤して貰った方が楽に違いない。
例え誰かがパソのＩＤＥをクラッシュさせても、その誰か以外は被害を受けないから・・・プリエンティブな開発環境ですね！
そう考えると、パソコンにインスト不要なNode.jsなサーバーでサーバーサイドなＩＤＥ（統合開発環境）とは、開発環境全体がノンプリエティブ化され、たった一つのプラグインのミスもお手上げ状態になりそう。
かなり運用が難しく、色々問題を抱えそうである。
単純にapacheをフロントエンドにしてＮｏｄｅ.js なIDEを設定ファイルで切り替えてリロードさせる様な運用をするだけでもかなり現場の雰囲気は違ってくるだろう。
そこが混在させる良さである。
全部Node.jsで作れば、そんなスイッチすら作る考えすら起きずＩＤＥを直結で利用になるだろうね。後で後悔してスイッチ付けるだろうけど・・・
そうならないクラウド（使用も運用もお手軽）なサーバーサイドＩＤＥがあればいいんだけどね。（笑