test

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

キープアライブ情報

このセクションでは、サーバーの HTTP レベルキープアライブシステムに関する情報が提供されます。

注 –

「キープアライブ (keep alive)」という名前を TCP の keep-alives と混同しないようにしてください。また、HTTP 1.1 では「キープアライブ」という名前が PersistentConnections に変更されましたが、Web Server では引き続き、それらの接続をキープアライブ接続と呼んでいます。

次の例は、perfdump で表示されるキープアライブ統計を示したものです。

KeepAliveInfo:
--------------------
KeepAliveCount        198/200
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     56844280
KeepAliveTimeouts     365589
KeepAliveTimeout      10 seconds

次の表に、管理コンソールで表示されるキープアライブ統計を示します。

表 2–3 キープアライブ統計情報

処理した接続の数 

0 

追加した接続の合計数 

198 

最大接続サイズ 

200 

フラッシュした接続の数 

0 

拒否された接続の数 

56844280 

終了したアイドル接続の数 

365589 

接続タイムアウト 

10 

HTTP 1.0 と HTTP 1.1 はどちらも、単一の HTTP セッションで複数の要求を送信する機能をサポートしています。Web サーバーは、新しい HTTP 要求を 1 秒間に数百件受信できます。すべての要求の接続をいつまでも開いたままにできると、サーバーは多くの接続で過負荷状態になってしまう可能性があります。UNIX および Linux システム上では、これにより、ほんのわずかな負荷でファイルテーブルのオーバーフローが発生する可能性があります。

この問題に対処するため、サーバーは、待機キープアライブ接続の最大数のカウンタを維持します。待機キープアライブ接続は、以前の要求の処理を完了し、その同じ接続上で新しい要求が到着するのを待っています。サーバー上で最大待機接続数を超える接続が開いた状態で、新しい接続がキープアライブ要求を待機している場合、サーバーはもっとも古い接続を閉じます。このアルゴリズムにより、サーバーが維持できる開いた待機キープアライブ接続の上限が保たれます。

Sun Java System Web Server は必ずしも、クライアントからのキープアライブ要求に従うとは限りません。次の条件が成立する場合には、クライアントがキープアライブ接続を要求しても、サーバーは接続を閉じます。

Web Server のキープアライブサブシステムは、きわめて高いスケーラビリティーを実現できるように設計されています。デフォルトの構成は、作業負荷が持続的でない場合 (つまり、KeepAlive ヘッダーを持たない HTTP 1.0 の場合) や、主にキープアライブ接続へのサービスを提供する低負荷システムで使用する場合には、最適でない可能性があります。

キープアライブカウント

perfdump のこのセクションには、次の 2 つの数値が含まれます。

チューニング

サーバーがもっとも古い接続を閉じる前に待機を同時に許可する接続の最大数を管理コンソールでチューニングするには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「最大接続数」フィールドを編集します。デフォルトは 200 です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで max-connections プロパティーを使用します。

注 –

最大接続数の設定に指定された接続数は、キープアライブスレッド間で均等に分割されます。最大接続数の設定がキープアライブスレッド数の設定で均等に分割できない場合、サーバーは、同時キープアライブ接続の最大数よりも若干多い値を許可する可能性があります。

キープアライブヒット数

キープアライブヒット数 (処理された接続の数) は、キープアライブ接続から要求が正常に受信された回数です。

この設定はチューニング不可能です。

キープアライブフラッシュ数

追加された接続の合計数がキープアライブ最大接続数の設定を超えたために、サーバーが接続を閉じなければいけなかった回数。このサーバーは、キープアライブ数が最大接続サイズを超えても既存の接続を閉じません。代わりに、新しいキープアライブ接続が拒否され、拒否された接続の数が増分されます。

キープアライブ拒否数

おそらく持続的接続が多すぎたために (あるいは追加された接続の合計数がキープアライブ最大接続数の設定を超えたときに)、サーバーが接続をキープアライブスレッドに渡せなかった回数。推奨のチューニングは、キープアライブ最大接続数を増やすことです。

キープアライブタイムアウト数

クライアント接続が何の活動も見られないままタイムアウトに達し、サーバーがそのアイドル状態のキープアライブ接続を閉じた回数。この統計は監視対象として有用ですが、推奨のチューニング方法は特にありません。

キープアライブタイムアウト

アイドル状態のキープアライブ接続が閉じられるまでの時間 (秒)。この値を管理コンソールで設定するには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「タイムアウト」フィールドを使用します。デフォルトは 30 秒ですが、これは、アイドル状態が 30 秒を超えると接続がタイムアウトすることを意味します。最大値は 3600 秒 (60 分) です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで timeout プロパティーを使用します。

キープアライブポーリング間隔

キープアライブポーリング間隔は、システムがキープアライブ接続に対するポーリングを行なって要求の有無を確認する間隔 (秒) を指定します。デフォルトは、許可される最小値である 0.001 秒です。これが小さな値に設定されているのは、CPU の使用率を犠牲にしてパフォーマンスを向上させるためです。

ポーリング間隔をチューニングするには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「ポーリング間隔」フィールドを編集します。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで poll-interval プロパティーを使用します。

キープアライブスレッド数

キープアライブシステムで使用されるスレッドの数を管理コンソールで構成するには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「スレッド数」フィールドを編集します。デフォルトは 1 です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで threads プロパティーを使用します。

HTTP 1.0 スタイルの作業負荷に対するチューニング

HTTP 1.0 では新しい受信接続が多数発生するため、1 待機ソケットあたりのアクセプタスレッド数のデフォルト値 1 は、最適であるとは言えません。HTTP 1.0 スタイルの作業負荷では、これを大きな数値に増やすとパフォーマンスが改善されるはずです。たとえば、2 個の CPU を備えたシステムの場合、これを 2 に設定することをお勧めします。また、キープアライブ接続数を 0 などに減らすこともお勧めします。

HTTP 1.0 スタイルの作業負荷では、多数の接続が確立され、終了されます。

サーバーが高負荷状態のときにブラウザから Web Server への接続でタイムアウトが発生する場合には、HTTP リスナーの待機キューサイズを 8192 などの大きな値に設定することで、HTTP リスナーのバックログキューのサイズを増やすことができます。

HTTP リスナーの待機キューは、ある待機ソケット上で保留される接続の最大数を指定します。バックログキューがいっぱいになった待機ソケット上で接続がタイムアウトすると、その接続は失敗します。

HTTP 1.1 スタイルの作業負荷に対するチューニング

一般に、サーバーによる持続的接続の処理をチューニングする場合、スループットと待ち時間はトレードオフの関係になります。キープアライブポーリング間隔とタイムアウトによって待ち時間が決まります。これらの設定の値を小さくすることの狙いは、ページの読み込み時間を短縮するなど、低負荷システムでの待ち時間を短縮することです。これらの設定の値を増やすことの狙いは、サーバーが 1 秒間に処理できる要求の数を増やすなど、高負荷システムでの全体的なスループットを高めることです。ただし、待ち時間が長すぎるのにクライアントが少なすぎる場合には、サーバーが不必要にアイドル状態になるため、全体的なスループットが低下します。結論として、ある特定の負荷状態におけるキープアライブサブシステムの一般的なチューニング規則は、次のようになります。

また、チャンクエンコーディングは、HTTP 1.1 の作業負荷でのパフォーマンスに影響を与える可能性があります。応答バッファーサイズのチューニングは、パフォーマンスに良い影響を与える可能性があります。構成の「パフォーマンス」タブ ⇒ 「HTTP」タブで応答バッファーサイズを大きくすると、応答がチャンクに分割される代わりに、Content-length: ヘッダーが送信されるようになります。CLI を使ってバッファーサイズを設定するには、wadm set-http-prop コマンドの output-buffer-size プロパティーを使用します。

また、obj.conf ファイル内で Service クラスの関数のバッファーサイズを UseOutputStreamSize パラメータを使って設定することもできます。UseOutputStreamSize は、output-buffer-size プロパティーを使って設定された値よりも優先されます。UseOutputStreamSize が設定されていない場合、Web Server は output-buffer-size の設定を使用します。output-buffer-size が設定されていない場合、Web Server は output-buffer-size のデフォルト値 8192 を使用します。

次の例は、CLI を使って出力バッファーサイズを増やしたあと、構成を配備する方法を示したものです (obj.conf で UseOutputStreamSize が指定されていない場合に使用される)。 

./wadm set-http-prop --user=admin-user --password-file=admin-password-file 
--config=config-name output-buffer-size=16384
./wadm deploy-config --user=admin-user --password-file=admin-password-file
 --config=config-name

次の例は、nsapi_test Service 関数のバッファーサイズを設定する方法を示したものです。

<Object name="nsapitest">
 ObjectType fn="force-type" type="magnus-internal/nsapitest"
 Service method=(GET) type="magnus-internal/nsapitest" fn="nsapi_test"
 UseOutputStreamSize=12288
</Object>