考えられる制約をいくつか挙げてみますが、他にもあるかもしれません。
Apacheが実行されているWebサーバー
使用されているファイル ハンドルの数を確認してください (Apache が css、javascript、または画像などの静的コンテンツを提供する場合)。
さらに、http 接続の数が制約になる場合があります (通常、同時ユーザーごとに 1 つ)。
もう 1 つの制約は、Tomcat にリクエストを渡す ajp ワーカー スレッドの数です。
メモリの制約要件はそれほど大きくないかもしれませんが、それはApacheが何をするかによって異なります.
Tomcat が実行されているアプリ サーバー
ここでは、セッションのサイズが制約になります。セッションのタイムアウトによっては、同時セッションの数が同時ユーザーの数よりもはるかに多くなる可能性があることに注意してください (すべてのユーザーが同時要求を実行する必要はありませんが、セッションにはメモリが必要です)。
さらに、サービスの実行に使用できるスレッドの数が制約になります。サービスの応答が速いほど、ブロックされるスレッドが少なくなるため、必要なスレッドも少なくなります。
Redis、postgres、および mongodb が実行されているデータベース サーバー。
データベースには少なくとも 2 つの制約があります。接続数 (db アクセスの要求ごとに少なくとも 1 つ必要) とクエリ キャッシュ用のメモリ (メモリが多いほど、キャッシュされるクエリ結果が多くなり、応答が速くなります)。
全体
5000 から 10000 の同時ユーザーが予想されるシステムの場合、クラスタリングと負荷分散を検討する必要があります。これにより、オンデマンドで調整でき (リソースが使い果たされている場合は別のノードを追加でき、ほとんどのリソースがまったく必要ない場合はノードを削除できます)、信頼性が高くなるという追加の利点があります (1 つのノードがダウンしている場合)。システムは遅くなる可能性がありますが、それでも実行されます)。
システムのプロファイリングを行うには、多数の同時アクセスをシミュレートし、主要なパラメーター (ファイル ハンドル、メモリ使用量、使用されるスレッド、データベース接続、http 接続など) を監視する必要があります。少数のユーザー (例: 10) から始めて、徐々に増やしていきます (例: 100、次に 1000 など)。アクセス時間が特定の (自己定義された) 制限を下回った場合は、ボトルネックを見つけ、より多くのリソースを提供して、再試行します。最終的には、いくつかの傾向 (たとえば、500 ユーザーあたりの累積セッション サイズが 1GB) を見つけて、より多くの同時ユーザーの概算を行うことができます。
同時ユーザーをシミュレートするには、Apache JMeterを参照してください。