ここでは、次のサーバーサブシステムに関するサーバーのスケーリングで最適なパフォーマンスを得るための推奨事項について説明します。
Application Server では、自動的に複数の CPU が利用されます。一般に、複数の CPU による効率はオペレーティングシステムと作業負荷によって異なりますが、通常は、プロセッサが多いほど動的コンテンツのパフォーマンスは向上します。
静的コンテンツには、CPU アクティビティーよりも、主に入出力 (I/O) アクティビティーが関係します。サーバーが適切に調整されている場合、主メモリーを増やせばコンテンツのキャッシュ量も増え、その結果、CPU アクティビティーに使用される時間に対して I/O アクティビティーに使用される時間の相対量が増えます。CPU 数を 2 倍にすると、サーブレットのパフォーマンスが 50 〜 80% 向上するということが、調査により判明しています。
サポートされているオペレーティングシステム別のメモリーに関する推奨事項については、『Sun Java System Application Server Enterprise Edition 8.2 リリースノート (UNIX 版)』の「ハードウェアとソフトウェアの要件」を参照してください。
OS、ドキュメントツリー、およびログファイルに十分な ディスク容量を用意することをお勧めします。ほとんどの場合は、合計 2G バイトで十分です。
OS、スワップファイルとページングファイル、Application Server ログ、およびドキュメントツリーを、それぞれ別個のハードドライブに配置します。このようにすると、ログドライブがログファイルでいっぱいになっても、OS に影響しません。また、OS のページングファイルによるドライブアクティビティーが発生しているかどうかを見分けることなども容易です。
OS ベンダーは、通常、スワップ空間やページング空間の割り当て量の推奨値を提示しています。Sun のテストによると、Application Server は、スワップ空間が RAM と同じ容量の場合に最適に動作し、ドキュメント ツリーのマッピングにも十分に対応できます。
アプリケーションに必要な帯域幅を決定するには、次の値を調べます。
サーバーで処理する必要があるピーク時の同時ユーザー数 (N peak)。
サイトの平均要求サイズ (r)。平均要求には、複数のドキュメントが含まれる場合があります。不確かな場合は、ホームページと、関連付けられたすべてのファイルとグラフィックスを使用します。
ピーク使用時に平均的なユーザーがドキュメントを快く待っていられる時間 (t) を決めます。
次に、必要な帯域幅を次のように計算します。
Npeakr / t
たとえば、ピーク時に 50 人のユーザーをサポートし、平均ドキュメントサイズが 24K バイトで、各ドキュメントを平均 5 秒で送信する場合は、240K バイト (1920K ビット/秒) 必要です。そのため、このサイトには 2 本の T1 回線 (それぞれが 1544K ビット/秒) が必要です。この帯域幅だと、オーバーヘッドがいくらか増えても対応できます。
サーバーのネットワークインタフェースカードは、接続される WAN 以上をサポートする必要があります。たとえば、最大で 3 本の T1 回線を使用する場合は、10BaseT インタフェースで対応できます。1 本の T3 回線 (45M ビット/秒) までは、100BaseT を使用できます。ただし、WAN の帯域幅が 50M ビット/秒を超える場合は、複数の 100BaseT インタフェースを設定するか、ギガビット Ethernet 技術を検討してください。