mod_wsgiを介してDjangoを実行しているときに、WSGIDaemonProcessで指定できるプロセスの数はいくつですか？

1つのボックスで独自のApache仮想ホストから実行している2つのサイト（スーパーユーザーとサーバーフォールト）があるとします。2つのサイトはDjangoを使用しており、Apacheでmod-wsgiを実行しています。サイトの1つの典型的な構成ファイルは次のようになります。

WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5

ホストは、Ubuntuを実行する4GBのRAMを備えたLinuxマシンです。2つのサイトに対して上記で指定する必要のあるプロセスの数を誰でも提案できますか？実際のスーパーユーザーおよびサーバーフォールトのサイトと同じトラフィックがあると仮定しましょう。

さて、実際のスーパーユーザーとサーバーフォールトのサイトにはどれくらいのトラフィックがありますか？仮説を立てるのに十分な情報がないと、答えを簡単にすることができません...

最悪の場合のプロセスカウントは、サイトが処理できる1秒あたりのピーク要求数を、すべての要求が最も遅いアクションに対して行われた場合に1つのプロセスが処理できる1秒あたりの要求数で割ったものである必要がありますそのアクションの処理時間の逆数）。req / secおよび時間測定の信頼区間に基づいて、適切と思われるファッジファクターを追加します。

平均ケースカウントは同じですが、要求/秒を各アクションの1秒あたりのリクエスト数の加重平均で除算します（ウェイトは、特定のアクションにヒットすると予想されるリクエストの割合です）。繰り返しますが、ファッジファクターは便利です。

マシン上で実行できるプロセスの実際の上限は、各プロセスが使用するメモリの上限によって決まります。1つのプロセスをスプールしてから、現実的なデータセット（たとえば、テストに50または100などのおもちゃデータセットを使用する場合）行の場合、アクションの1つがテーブル内のすべての行を取得して操作する場合、そのテーブルが10,000行になったときの適切な測定ではありません）、メモリ使用量がどのように膨らむかを確認します。特定のメモリ使用量のしきい値に達するワーカーを刈り込むスクリプトを使用して、プロセスごとのメモリ使用量を人為的に制限できます。そのしきい値を低く設定しすぎると、厄介な問題が発生するリスクがあります。

メモリ使用量の図を取得したら、システムオーバーヘッドのためにある程度のメモリを差し引いて（私は自分で512MBが好きです）、同じマシン（データベースなど）で他のプロセスを実行している場合はさらに山を差し引いてから、ディスクキャッシュ領域が不足しないようにするために、さらにいくつかを実行します（ディスクのワーキングセットのサイズによって異なりますが、512MB以上を使用します）。これは、上限を得るためにプロセスごとのメモリ使用量で割ったメモリ量です。

ピーク負荷に対応するために必要なプロセスの数が、ボックスに収まるプロセスの数よりも多い場合、より多くのマシンが必要です（または、最も単純な場合、データベースを別のマシンに移動するため）。

Webサイトを1つの小さなシンプルなSFポストに拡張した数年の経験があります。

wombleの答えは素晴らしかったが、未経験者を理解して応募するのは少し難しい。いくつかの経験的な数値、および「シンプルコンテンツ」と「eコマース」アプリケーションの比較を示したいと思います。

mod_wsgiの適切な構成に関連して、さまざまなユースケースを設定することについてはあまり資料がないので、ここで少し散文を使用してもかまいません。

A）CMSサイトとマイクロサイト

私たちはいくつかの顧客のウェブサイトを運営しています。それらのほとんどは、主にコンテンツサイトまたはdjango CMSをホストするマイクロサイト、いくつかのカスタムフォーム、およびスケジュールされたバックグラウンドタスク用のCeleryです。これらのサイトはリソースを必要とせず、それらのいくつかは32 GB RAMを搭載した単一の4コアIntel 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 RAMを搭載した2 CPU 6コアIntel Xeonは、その負荷の下で25％未満のCPU使用率で実行され、RAM使用率もほぼ一定で25％未満に留まります。ここでは単一のサイト専用のマシンを使用しているため、他のサイトが必要とするリソースを盗むことはありません。

結論

より多くのプロセスを使用することは、Apacheが利用可能なシステムリソースを利用できるようにするかどうかのトレードオフです。「攻撃」状態で安定したサーバーシステム（Webサイトではありません！）を維持する場合は、数値を低くします。必要なときにシステムリソース（CPU、RAM）を使用してApacheを支援したい場合は、より大きな数を選択します。どれだけ高くすることができるかは、上記の受け入れられた答えで概説されているように計算され、最終的に利用可能なCPUパワーとRAMによって制約されます。

（PS：modwsgiプロジェクトwiki のConfigurationDirectivesセクションは、Apacheのようなバックグラウンドで読むために枕の下に置いておきます。また、Apacheサーバーの開いている接続を理解して監視してください。