これは間違いなく、科学というより芸術です。
覚えておかなければならないことは、プログラミングや IT の多くのことと同様に、Web サイトはチェーンの中で最も遅いリンクと同じくらい遅くなるということです。つまり、帯域幅、Web サーバー、ディスク I/O、メモリなどのボトルネックが発生します。ウェブサイトの速度を制限するデータベース、ファイアウォールなど。
Web サイトを調整して成長させるには、成長するにつれてこれらの問題を特定し、対処する必要があります。ある時点では RAM を追加する必要があり、別の時点では別の CPU が必要になる場合があります。また、メモリが問題ではないため、メモリを追加しても意味がない場合もあります。
同様に、特定のリソースの不足をマスクすることができます。たとえば、システムが絶えずスワップ (ページ フォールト) するため、集中的なディスク I/O によってメモリの不足をマスクできますが、ディスク I/O は問題ではありません。
それで、あなたは何をしますか?
最初に、一般的なユーザーが何をどの程度行うかを特定する (または合理的な推測をする) 必要があります。理想的には、JMeter などのソフトウェアを使用して 100 人または 1000 人、または必要な数のユーザーをモデル化して、Web サイトがどのようにスケーリングするか、必要な帯域幅の量などを把握できます。100 人、500 人、1000 人、2000 人のユーザーをモデル化することで、Web サイトがどれだけ直線的にスケーリングするかを確認できると思います。
1000 ユーザーをサポートするには 1 ギガの RAM が必要ですが、2000 には 4 ギガが必要です。これは、Web サイトをスケールアップする際の問題を明らかにする非線形スケーラビリティの例です。そして、それはパフォーマンス テストによって明らかになるようなものです。
正直なところ、最近のハードウェアは非常に安価であるため、最大かつ最も人気のあるサイトを除いて、問題になることはめったにありません (1 万ドルで、16G の RAM と 4 ~ 8 コアを備えたサーバーを 1 台または 2 台購入できます)。共有ホスティングと VPS ホスティングは別の話です。通常、必要なメモリ、帯域幅、およびディスク容量に対してのみ支払いたいからです。幸いなことに、これらの種類のソリューションでは、非常に簡単にアップグレードできる傾向があります (少なくとも、最終的にホスティングに専念しなければならなくなるまで)。
プロジェクトの開始時に、「封筒の裏側」の見積もりと呼ばれるものを行うことで、いくつかの汚い見積もりを行うことができます。主要なクエリを 100 回実行して必要な CPU 時間を計算し、モックアップされたページを 100 回ヒットして生成される帯域幅を計算します。これらの大まかな見積もりと、ユーザーがサイトをどのように使用するかについての推測を組み合わせることで、必要なものの概算 (できれば 2 ~ 3 倍以内) が得られます。