Apache / PHPのスケーリングは、CPUコアの数を最大化するのと同じくらい簡単ですか？
4コアと8スレッドのInteli7CPUを搭載したLinux/Debianサーバーがあります。ヘビーデューティーのApache/PHPジョブを実行すると、1つのスレッドが使用され、同時にApache/PHPジョブを実行すると、それぞれが独自のスレッドを使用します。
したがって、大量のトラフィックに備える必要がある場合、十分なメモリがあり、データベース/ファイルシステムに十分なメモリがあれば、より多くの同時ジョブを処理できるように（他のCPUを選択して）コアの数を最大化するだけです。余分な課題を提起しませんか？
私は8と10のジョブを同時に実行しようとしましたが、すべてのスレッドを使用し、CPU使用率はほぼ100％でした（ただし、完璧に実行されました）。したがって、理論は完全にずれているわけではないようですが、この線形思考を無効にする可能性のあるものは他にありますか？
あるいは、複数のサーバーを備えた負荷分散システムを使用することもできますが、単一のサーバーでどこまで到達できるのでしょうか。
PS。 Apache/PHPはスレッドセーフを無効にしてmod_phpを使用しているため、PreforkMPMを使用します。スレッドセーフについて確信が持てないので、あえてワーカーMPMを使用するかどうかはわかりません...
PSS。また、私は必ずしもより良いパフォーマンスを求めているわけではありません。主に、より多くのトラフィック/より多くの同時ジョブを処理できるようにするだけです。
あなたが説明していること（100％のCPU使用率）から、アプリケーションはCPUバウンドのようです。したがって、CPUコアを追加するか、コアが高速なマシンに移行すると、パフォーマンスが向上する可能性があります。
多くのクラウドプロバイダーは、多くのCPUコアと大量のRAMを備えた強力な仮想マシンをレンタルするために1時間あたりわずか数セントを請求します。 16コアまたは32コアでテストして、CPU /コアの数に応じてパフォーマンスがどのように変化するかを確認してください。
はい。システムの数を増やす前に、まずシステムのコアの数を増やすことをお勧めします。
スケーラビリティには常に制限があり、システムのどのコンポーネントでもかまいません。
スループットが直線的に増加し、応答時間がそれほどひどくなかった場合、CPUは現在のところ制限要因ではありません。より多くのCPUでテストを続けます。大きく考えてください。さまざまなクラウドから非常に大きなVMをレンタルできます。 VMが1つのCPUソケットよりも大きい場合、NUMA効果が見られるようになる可能性があります。
理想的には、スループットは他のボトルネックにぶつかるために増加を停止しますが、急速に低下する可能性もあります。見つける唯一の方法はテストすることです。
高可用性など、複数の負荷分散されたバックエンドを使用する非スケーラビリティの理由があります。