写真付きの明確な例で何かを説明することは常に良いことです。 したがって、小さな「真空中の球形サイト」を考え出し、いくつかの条件を受け入れます。
次の2つの要求のみを理解するWebサイトがあるとします。
リクエストAは1秒で実行され、データベースへのアクセスは必要ありません。
リクエストBは5秒で実行され、そのうち4つはDBの応答を待つことに費やされます。
また、リクエスト間の時間は少なくとも1秒であることに同意します。
Php
phpでの動作を見てみましょう。
最も単純な形式では、サーバーアーキテクチャは次のようになります。
ここでは以下が重要です。クライアントからリクエストを受信したWebサーバーは、それをphpプロセスに転送します。 次に、phpプロセスは一度に1つの要求を処理できます。作業が完了すると、結果がWebサーバーに返され、プロセス自体が存在しなくなります。 応答を受信したWebサーバーは、結果をクライアントに送信し、接続を閉じます。
phpプロセスが1つしかない場合、サーバーの操作を次の図に表示できます。
図から、これまでのところリクエストのみが届き、サーバーはそれらに積極的に応答し、通常は割り当てられたタスクを実行しますが、リクエストBが到着するとすぐに、サーバーはリクエストBへの回答が準備できるまで応答を停止しますまた、この図は、リクエストBのほとんどの時間、「全員」がデータベースの結果を待っていることを示しています。
この問題を解決するには、PHPプロセスの数を増やす必要があります。2倍に増やしましょう。その結果、スキームは次の形式を取ります。
この図は、リクエストBが最初のphpプロセスで処理中に「ハング」する一方で、サーバーが他のリクエストに引き続き応答することを示しています。 2つのリクエストBが到着するまですべてがうまくいき、両方のphpプロセスがデータベースからの応答を待って「ハング」し、サーバー全体が応答するまで応答が停止します。
さて、私たちはすでに何をすべきか知っていますか？ そうです、phpプロセスの数を20から30まで増やして増やしましょう。実際には問題は少し後退し、30のリクエストが来た瞬間にBが来ますが、問題はなくなったようです。 全体的な問題は、無限に多くのphpプロセスを作成できず、それらを法外な量で増やす方法が間違っていることです。
これらのスキームから学ぶべき最も重要なことは、phpのデータベース操作が同期的に実行されることです。 この場合、データベースへのクエリを実行したプロセスは、他のリクエストを処理できず、データベースからの応答を待つ「ハング」（何もしない）を強制されます。
nodejs
nodejsを提供するものは何ですか？
最初に、単純なサーバーがどのように見えるかを見てみましょう。
すぐに目を引くのは、サーバーにリクエストAおよびBのハンドラーとWebサーバー自体が直接含まれていることです。 これらはすべて1つのノードプロセスでスピンし、常にメモリにハングしています。
作業スキームを見てみましょう。
この図は、データベースからの応答を見込んで、リクエストBがサーバーを「フリーズ」させないことを明確に示しています。 サーバーはリクエストBを受信すると、単にリクエストを生成してデータベースに送信し、データベースからのレスポンスを受信するとすぐに結果をクライアントに返します。 nodejsの場合、リクエストBがどのようにいくつ送信されるかは関係ありません。データベースからの応答を見込んで「フリーズ」に至ることはありません。
おわりに
そして結論は簡単です。
nodejsに来ても、phpでやったようにしようとしないでください。
非同期環境で作業し、ブロッキングにつながる操作を使用しないでください。これにより、nodejsのアイデアが失われます。
nodejsは単一のプロセスで多くのリクエストを処理し、常にメモリにハングアップするので、変数とメモリの無駄遣いを追跡してください。
1つのサイトで50個のノードプロセスを実行する価値はありません。一般に、プロセッサ上のコアの数を超えて実行するべきではありません。
nodejsは特効薬ではなく、単に使用するだけではスケーリングの問題を解決できず、高負荷の下で動作しません。