質問はタイトルにあります。つまり、Nginx が node.js の同じイベント駆動型非同期 IO モデルとして機能するのであれば、非同期スタイルのコードを記述する必要がないのはなぜでしょうか? Nginxは実際にコードを実行するのではなく、実行できる人にプロキシします。では、なぜ node はそうしないのでしょうか? 現在の Ngninx のやり方に欠けているものはありますか? または、ノードからさらに何かを得ることができますか (非同期コードを書くという苦痛は別として)?
Ps。より具体的には、Nginx+php-fpm または Nginx+wsgi+python/ruby は、ノードが主張するパフォーマンスまたはコンピューティング リソースの使用に関して、ノードのみとどのように異なりますか? ノードは既存の FastCGI モデルをそのまま使用して、同期スタイルの JavaScript インタープリターになり、Web サーバーに非同期ジョブを実行させることはできませんか?
NodeJSグーグルグループからのクロスポスト：
さて、私はあなたの質問に答えるために最善を尽くします：
Nginxは、リクエストのみをプロキシするWebサーバーです。ここで、Nginx + php+fpmまたはNginx+wsgi + rubyを例にとると、同期的に実行されているWebサーバーの前に非同期のイベントWebサーバーがあります。したがって、Nginxは可能な限り多くの接続をaccept（）し、それらすべてがキューに入れられます。Nginxからバックエンド同期サーバーへのリクエストは非同期になります。ただし、accept（）も実行するバックエンド同期サーバーは接続をキューに入れていません。一度に1つのリクエストのみを処理でき（シングルスレッドであると見なす）、一度に複数のリクエストを処理できます（prefork / fork（slow）/ multithreaded->スレッド作成時間などの独自の欠点があります（スレッドプールで回避できますが、実装するPITA）、コンテキストスイッチ、スレッドデッドロック、
Nginxがヒットしているバックエンドサーバーへのルートが2つあるとします。
/ 404、/login。
/loginルートが多くのI/Oを実行していて、/404に対して別の要求が行われた場合、/ 404ページのレンダリングは、/ loginの要求の完了に依存します（プロセスがブロックされているため）。したがって、基本的に、リクエストへの応答は、I/Oを実行するのに最も時間がかかるリクエストに依存します。そのため、Nginxが非同期でイベントが発生した場合でも、リクエストの応答時間は、終了までに最も時間がかかる1つのリクエストに完全に依存します（原因：同期バックエンドサーバー）。
ここで、NodeJSを例にとると、すべてが非同期でイベントが発生します。ファイル/ネットワークI/Oなどです。したがって、プロセスを妨げるものは何もありません。したがって、前の例では、/loginrouteが多くのI/Oを実行している場合でも、すべて非同期で/404ページがすぐにレンダリングされます。
私の説明は非常に初歩的なものです。しかし、私はそれがあなたにもっと明確さを与えるべきだと思います。
nginx は、単純な静的 HTTP およびプロキシ サーバーです。Node.js は、フル機能のアプリケーション プラットフォームです。
より専門化されたアプリケーションが、直接制御する必要のないすべての内部動作を抽象化することを期待しないのはなぜですか?
あなたの PS はこの質問によく似ており、特に Node.JS を HTTP サーバーとして使用することに関心があります。その質問が閉じられたときにv0.4.12がリリースされたばかりであることに注意してください.v0.8.5は現時点で最新の安定版リリースです。とにかく重要な点は、達成しようとしているものに依存するということです。
このブログ投稿では、1 台のサーバーで 250,000 の同時接続を実現する Node.JS ベースのセットアップについて説明しています。Google で簡単に検索すると、nginx+php で同様のことを試みている人々が、はるかに多くのハードウェア リソースを使用して 100k に到達するのに苦労していることがわかります。