mod_wsgiからDjangoを実行しているときに、WSGIDaemonProcessで指定するプロセスの数は？
1つのボックスで独自のApache仮想ホストから実行している2つのサイト（スーパーユーザーとサーバー障害）があるとします。 2つのサイトはDjangoを搭載しており、mod-wsgiを使用してApacheで実行されています。サイトの1つの一般的な構成ファイルは次のようになります。
WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5
ホストは、4 GBのLinuxマシンで、RAM Ubuntuを実行しています。2つのサイトで上記で指定する必要があるプロセスの数を提案できますか？実際のスーパーユーザーと同じトラフィックがあり、 Serverfaultサイト。
まあ、どのくらいのトラフィックdo実際のスーパーユーザーとサーバーフォールトのサイトにありますか？仮説は、答えを簡単にするのに十分な情報がない場合、あまり役に立ちません...
最悪の場合のプロセス数は、サイトが処理できる1秒あたりの要求のピーク数を、すべての要求が最も遅いアクションに対して行われた場合に1つのプロセスが処理できる1秒あたりの要求数で割ったものです（したがって、そのアクションの処理時間の逆数）。 req/secの信頼区間と時間測定に基づいて、適切と思われるファッジファクターを追加します。
平均ケースカウントは同じですが、各アクションのリクエスト/秒の加重平均値でリクエスト/秒を割ります（ウェイトは、特定のアクションにヒットすると予想されるリクエストの割合です）。繰り返しになりますが、ファッジ要因が役立ちます。
マシン上で実行できるプロセス数の実際の上限は、各プロセスが使用するメモリの上限によって決まります。 1つのプロセスをスプールしてから、現実的なデータセットを使用して、メモリを大量に消費するさまざまなアクション（通常、大量のデータを取得して処理するアクション）を実行します（テスト用におもちゃのデータセットを使用する場合、50または100など）行の場合、アクションの1つがテーブルのすべての行を取得して操作する場合、そのテーブルが10,000行に増えたときの測定値としては適切ではありません）。特定のメモリ使用量のしきい値に達したワーカーを刈り取るスクリプトを使用して、プロセスごとのメモリ使用量を人為的に制限することができます。このしきい値を低く設定しすぎると、厄介な問題が発生するリスクがあります。
メモリ使用量の数値を取得したら、システムオーバーヘッド用のメモリの一部を差し引いて（私自身は512MBが好きです）、同じマシンで（データベースのように）他のプロセスを実行している場合はさらに山を差し引いてから、ディスクキャッシュスペースが不足しないようにするためのもう1つの方法（ディスクのワーキングセットのサイズによって異なりますが、512MB以上を使用します）。これは、上限を取得するためにプロセスごとのメモリ使用量で割ったメモリの量です。
ピーク負荷を処理するために必要なプロセスの数が、ボックスに収めることができるプロセスの数よりも多い場合は、より多くのマシンが必要です（または、最も単純なケースでは、データベースを別のマシンに移動します）。
あなたは、数年間のウェブサイトのスケーリングの経験を1つの小さくてシンプルなSFポストに抽出しました。
womble の答えは素晴らしいですが、理解が不十分で、経験の浅い人に申し込むことはできません。いくつかの経験的な数値と、「単純なコンテンツ」と「eコマース」アプリケーションの比較を示したいと思います。
Mod_wsgiの適切な構成に関連してさまざまなユースケースを設定することに関する資料はあまりないので、ここで少し散文を使用してもかまいません。
A）CMSサイトとマイクロサイト
私たちはいくつかの顧客Webサイトを運営しています。それらのほとんどは、主にコンテンツサイトまたはマイクロサイトをホストしていますDjango= CMS、いくつかのカスタムフォーム、場合によってはスケジュールされたバックグラウンドタスク用のCelery。これらのサイトはリソースに飢えていません。いくつか32 GBのRAMを搭載した単一の4コアインテルXeonで並行して問題なく動作します。このようなサイトのそれぞれに使用する構成は次のとおりです。
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
1台のサーバーで約40のサイトについて話しているが、それらのほとんどは、ステージングサイトがスタンバイで実行されている。 2つのプロセス（既定ではそれぞれ15スレッド）を使用すると、サーバーリソースを割り当てる機能に制限がありますが、サイトは十分に機能します。このセットアップで十分である理由は、（CMS）アプリケーションの単純な性質で正当化できます。要求が完了するまでに数ミリ秒以上かかることはありません。 Apacheは常にリラックスした状態を保ち、CPU負荷も緩和されます。
B）eコマースサイト
私たちが行っているより複雑なサイトの特徴は、計算コストが低いローカル操作ですが、トランザクション時間の点で高価な外部依存関係（予約データを提供するWebサービスなど）です。外部要求を伴う操作は、スレッドをはるかに長い時間占有するため、同じ数のユーザーに対応するには、より多くのスレッドが必要です（上記の単純なCMSサイトと比較して）。さらに悪いことに、外部サービスがリクエストにすぐに応答できない場合、スレッドがブロックされることがあります。これにより、使用可能なすべてのmod_wsgiスレッドが使い切られて待機がブロックされるまで、スレッドが同じサービスキューにリクエストを送信するという不愉快な副作用が発生する可能性があります。
これらのシナリオでは、大きな違いを感じずに6プロセスを使用しようとしましたが、結果として12はパフォーマンスと動作の安定性において比類のない向上を示しました。
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
150および250の並列ユーザーによるいくつかの単純な負荷テストは、サイトの応答性を維持することで簡単に処理されます（一方、2プロセスでは、サイトは使用できず、50ユーザーの並列処理ができません）。 32 GBの2 CPU 6コアIntel Xeon RAMは、その負荷の下でCPU使用率が25％をはるかに下回ります。RAM使用率は、25％未満でほぼ一定ですまた、ここでは単一のサイト専用のマシンを使用しているため、他のサイトで必要になる可能性があるリソースを盗むことはありません。
結論
より多くのプロセスを使用することは、Apacheが利用可能なシステムリソースを利用できるようにするかどうかのトレードオフです。 「攻撃」条件下で安定したサーバーシステム（ウェブサイトではない！）を維持したい場合は、数を少なくしてください。必要に応じてシステムリソース（CPU、RAM）の使用をApacheに支援させたい場合は、より大きな数を選択してください。どれくらいの高さまで計算できるかは、上記の受け入れられた回答で概説されているように計算され、最終的には使用可能なCPUパワーとRAMによって制約されます。
（追記：Apacheのような背景を読むために、枕の下にmodwsgiプロジェクトwikiの ConfigurationDirectivesセクション を保持しています。 Apacheサーバーの開いている接続 を理解して監視してください。 ）