これは、Webサイトの容量計画に関する標準的な質問です。
関連する：
WebサイトおよびWebアプリケーションのキャパシティプランニングの推奨ツールおよび方法は何ですか？
さまざまなWebサーバー、フレームワークなどのさまざまなツールとテクニック、およびWebサーバー全般に適用されるベストプラクティスについてお気軽にご説明ください。
これは、Webサイトの容量計画に関する標準的な質問です。
関連する：
WebサイトおよびWebアプリケーションのキャパシティプランニングの推奨ツールおよび方法は何ですか？
さまざまなWebサーバー、フレームワークなどのさまざまなツールとテクニック、およびWebサーバー全般に適用されるベストプラクティスについてお気軽にご説明ください。
回答:
簡単な答えは次のとおりです。あなた以外の誰もこの質問に答えることができません。
長い答えは、特定のワークロードのベンチマークは、「文字列の長さはどれくらいですか？」
単純な1ページの静的WebサイトをPentium Pro 150でホストし、それでも毎日何千ものインプレッションを配信できます。
この質問に答えるために必要な基本的なアプローチは、それを試して、何が起こるかを確認することです。システムがどこで座屈するかを見るために、システムに人為的に圧力をかけるために使用できるツールがたくさんあります。
これの簡単な概要は次のとおりです。
基本的に、ある程度の負荷をテストするには、テスト対象が必要です。テスト対象の環境をセットアップします。これは、可能であれば、運用ハードウェアにかなり近い推測である必要があります。そうでない場合、データを外挿したままになります。
サーバー、アカウント、Webサイト、帯域幅などをセットアップします。VMでこれを行っても、結果をスケーリングする準備ができていれば問題ありません。
そこで、中規模の仮想マシン（2コア、512 MB RAM、4 GB HDD）をセットアップし、お気に入りのロードバランサーをVMのRed Hat Linuxhaproxy内にインストールします。
また、ロードバランサーのストレステストに使用するロードバランサーの背後に2つのWebサーバーを配置します。これら2つのWebサーバーは、稼働中のシステムとまったく同じようにセットアップされています。
監視するにはいくつかのメトリックが必要になるため、Webサーバーに到達するリクエストの数と、ユーザーが2秒を超える応答時間を取得する前に1秒間に絞り込めるリクエストの数を測定します。
また、haproxyインスタンスのRAM、CPU、およびディスクの使用状況を監視して、ロードバランサーが接続を処理できることを確認します。
これを行う方法はプラットフォームに大きく依存し、この回答の範囲外です。Webサーバーのログファイルを確認したり、パフォーマンスカウンターを開始したり、ストレステストツールのレポート機能に依存したりする必要がある場合があります。
常に監視したいいくつかのこと：
また、具体的にテストする対象に応じて、SQLデッドロック、シーク時間などを調べることもできます。
これは物事が楽しくなるところです。次に、テスト負荷をシミュレートする必要があります。構成可能なオプションを使用して、これを行うことができる多くのツールがあります。
任意の番号を選択してください。システムが1分間に10,000ヒットでどのように応答するかを確認するとします。このステップを何度も繰り返し、システムの応答を確認するためにその番号を上下に調整するため、選択する番号は重要ではありません。
理想的には、これらの10,000のリクエストを複数の負荷テストクライアント/ノードに分散して、単一のクライアントがリクエストのボトルネックにならないようにする必要があります。たとえば、JMeterのリモートテストは、制御するJmeterマシンから複数のクライアントを起動するための中央インターフェイスを提供します。
魔法のGoボタンを押して、Webサーバーが溶けてクラッシュするのを見てください。
したがって、ステップ2で収集したメトリックに戻る必要があります。10,000の同時接続では、haproxyボックスはほとんど汗をかいていますが、2つのWebサーバーでの応答時間は5秒以上です。それはクールではありません-応答時間は2秒を目指しています。そのため、いくつかの変更を加える必要があります。
次に、Webサイトを2倍以上高速化する必要があります。そのため、スケールアップまたはスケールアウトする必要があることがわかります。
スケールアップするには、より大きなWebサーバー、より多くのRAM、より高速なディスクを入手します。
スケールアウトするには、サーバーを増やします。
この決定を行うには、ステップ2のメトリックとテストを使用します。たとえば、テスト中にディスクレイテンシが非常に大きいことがわかった場合、スケールアップしてより高速なハードドライブを取得する必要があることがわかります。
テスト中にプロセッサが100％になっていることがわかった場合、おそらく既存のサーバーへの負荷を軽減するためにWebサーバーを追加するためにスケールアウトする必要があります。
一般的な正しい答えも間違った答えもありません。あなたにとって正しいものだけがあります。スケールアップしてみてください。それでもうまくいかない場合は、スケールアウトしてください。それともそうではない、それはあなた次第であり、一部は箱の外で考える。
スケールアウトするとします。そこで、2つのWebサーバー（VM）のクローンを作成することにし、4つのWebサーバーができました。
手順3からやり直します。期待どおりに動作しないことがわかった場合（たとえば、Webサーバーを2倍にしたが、応答時間は2秒以上です）、他のボトルネックを調べます。たとえば、Webサーバーを2倍にしたが、まだデータベースサーバーが壊れているとします。または、より多くのVMを複製しましたが、それらは同じ物理ホスト上にあるため、サーバーリソースのより高い競合のみを達成しました。
その後、この手順を使用して、システムの他の部分をテストできます。ロードバランサーにアクセスする代わりに、Webサーバーに直接アクセスするか、SQLベンチマークツールを使用してSQLサーバーにアクセスしてください。
キャパシティプランニングは面倒な作業です。それは芸術と同じくらい科学です（間違いなく暗いものです）。
あなたの最良の場合は、十分な情報に基づいた決定を下し、運命/運が現実にあなたの仮定を満たすことによってあなたを支持することです。あなたの能力が現実と一致する仮定が必要な場合、あなたは神秘的なヨギのように見えます。残念ながら、あなたの仮定が現実を超える場合、あなたはオーバーシュートし、使い果たしているように見えます。さらに残念なことに、仮定が最終的な現実を下回る（または正しくない）場合、必要な能力が不足し、うめきインフラストラクチャの障害を軽減するために急いでやり直さなければならないため、能力が不足しているように見えます。
プレッシャーはない...
残念ながら、キャパシティプランニングのダークアートは、単一のサーバーフォールトの答えに合理的に蒸留できる以上のものです。本当に、それは本に値する話題です。
幸いなことに、そのような本があります。「キャパシティプランニングの技術」
Mark Hendersonの投稿を拡張するために、Apache専用のこれを書いています。彼が言ったことを繰り返しますが、「簡単な答えは、あなた以外の誰もこの質問に答えることができないということです」この回答のテキストは、Drupal Webサイトのパフォーマンスに関する同様の質問に対する私の回答から大きく引用されています。
Apacheは、おそらく最も人気のあるWebサーバーの1つではありますが、そうではありません。これはオープンソースであり、依然として積極的に維持されています。LinuxとWindowsの両方のオペレーティングシステムで実行できますが、Linux / Unixの世界ではより人気があります。
すぐに使用できるApache構成を使用しないでください。常にApacheをサイトに合わせて調整する必要があります。CentOS のメインApache構成ファイルはに/etc/httpd/conf/httpd.confあり、UbuntuシステムのメインApache構成ファイルは通常にあり/etc/apache2/apache2.confます。追加の設定ファイルは、仮想ホストなどに使用されます。
多くのソフトウェアと同様に、Apacheは特定のWebサイトのニーズに応じて柔軟にカスタマイズできるように構築されています。Apacheを使用してネットワークポートにバインドし、要求を受け入れて処理するように構成できる、さまざまなマルチプロセッシングモジュールがあります。
CentOSおよびUbuntuサーバーに付属するデフォルトのApacheインストールでは、ほとんどの場合、MPM " mod_prefork "が使用されます。mod_preforkを使用していると仮定します（よくわからない場合は、それが発生する可能性が高くなりますが、それを決定できるのはあなただけです）。
MaxClients＆ServerLimit変数。これは確かにすべての答えではありません。Apacheサーバーのチューニングには時間がかかり、適切に動作するには経験が必要です。