Sun Java System Web Server 7.0 パフォーマンスのチューニング、サイジング、およびスケーリング

第 5 章サーバーのサイジングとスケーリング

この章では、サーバーのサブシステムを検査するとともに、最適なパフォーマンスのための推奨事項を提供します。この章の内容は、次のとおりです。

64 ビットサーバー

64 ビットサーバー (Solaris SPARC および AMD64 プラットフォームでのみ使用可能) は、32 ビットバージョンに比べて拡張性があります。システムに 4G バイトを超える RAM が実装されている場合は、64 ビットサーバーを使用できます。32 ビットサーバーと比較した場合の 64 ビットサーバーのいくつかの利点を次に示します。

静的コンテンツのためのファイルキャッシュの容量が大きい
64 ビット JVM のために同時サーブレットセッションの数が多い

プロセッサ

Solaris と Windows の場合、Web Server は複数の CPU を透過的に活用します。一般に、複数の CPU の有効性は、オペレーティングシステムや作業負荷によって異なります。動的コンテンツのパフォーマンスは、システムにプロセッサが追加されるに従って向上します。静的コンテンツは大部分が IO 処理であり、主記憶が増えるとコンテンツのキャッシュが増えることになる (サーバーがメモリーを活用するようにチューニングされていることが前提) ため、CPU ではなく IO アクティビティーにより多くの時間が費やされます。

メモリー

ベースラインとして、Web Server には 64M バイトの RAM が必要です。複数の CPU の場合は、CPU ごとに少なくとも 64M バイトが必要です。たとえば、CPU が 4 個の場合に最適なパフォーマンスを得るには、少なくとも 256M バイトの RAM をインストールするようにしてください。また、並行ユーザーのピーク数が多い場合も、追加のスレッドが余分な RAM を使用できるようにしてください。並行ユーザー数が 50 を超えたら、ピーク並行ユーザーごとに余分に 512K バイトを追加してください。

ドライブ領域

OS、ドキュメントツリー、およびログファイルに十分なドライブ領域を確保してください。ほとんどの場合は、全体で 2G バイトあれば十分です。

OS、スワップ/ページングファイル、Web Server ログ、およびドキュメントツリーを、それぞれ個別のハードドライブに配置します。ログドライブがログファイルでいっぱいになっても、OS には影響しません。また、たとえば、OS ページングファイルによってドライブアクティビティーが発生しているかどうかを検出することもできます。

OS ベンダーから、どの程度のスワップまたはページング領域を割り当てるべきかについての、特定の推奨事項が得られる可能性があります。テストによると、Web Server は、スワップ空間が RAM に等しい容量に加えて、ドキュメントツリーを十分にマップできるだけ存在する場合に最適なパフォーマンスを発揮します。

ネットワーキング

インターネットサイトの場合は、サーバーで処理する必要のある並行ユーザーのピーク数を特定し、そのユーザー数にサイトの平均要求サイズを掛けます。平均的な要求には、複数のドキュメントが含まれる可能性があります。はっきりしない場合は、ホームページと、それに関連付けられたすべてのサブフレームおよびグラフィックスを使用してみてください。

次に、ピーク使用時に、平均的なユーザーがドキュメントを我慢して待つことができる時間を特定します。その秒数で割ります。それが、サーバーに必要な WAN 帯域幅です。

たとえば、ピーク時に、平均ドキュメントサイズが 24K バイトで、各ドキュメントを平均 5 秒で転送している 50 ユーザーをサポートするには、240K バイト/秒 (1920 Kbps) が必要です。したがって、サイトには 2 つの T1 回線 (それぞれ 1544 Kbps) が必要です。また、これにより、成長のためのある程度のオーバーヘッドも可能になります。

サーバーのネットワークインタフェースカードでは、接続されている WAN を超える容量をサポートするようにしてください。たとえば、T1 回線 3 つまでは、10BaseT インタフェースで間に合います。T3 回線 (45 Mbps) 1 つまでは、100BaseT を使用できます。ただし、50 Mbps を超える WAN 帯域幅の場合は、複数の 100BaseT インタフェースの設定を考慮するか、またはギガビット Ethernet テクノロジを検討してください。