第 3 章 一般的なパフォーマンスの問題

この章では、Web サイトの一般的なパフォーマンスの問題について説明します。この章の内容は、次のとおりです。

• 「check-acl Server Application Function」

• 「メモリー不足の状況」

• 「少なすぎるスレッド」

• 「キャッシュが活用されていない」

• 「キープアライブ接続がフラッシュされる」

• 「ログファイルモード」

プラットフォーム固有の問題については、第 4 章「プラットフォーム固有の問題と注意事項」を参照してください。

check-acl Server Application Function

サーバーの最適なパフォーマンスを得るために、ACL は、必要な場合にのみ使用してください。

サーバーには、サーバーへの書き込みアクセスを all にのみ許可するデフォルト ACL を含む ACL ファイルと、anybody への書き込みアクセスを制限するための es-internal ACL が設定されています。後者の ACL によって、サーバー内のマニュアル、アイコン、および検索 UI ファイルが保護されます。

デフォルトの obj.conf ファイルには、読み取り専用にする必要のあるディレクトリを es-internal オブジェクトにマップするための NameTrans 行が含まれています。このオブジェクトには、さらに、es-internal ACL のための check-acl SAF が含まれています。

また、デフォルトオブジェクトにも、デフォルト ACL のための check-acl SAF が含まれています。

ACL によって保護されていない URI のデフォルトオブジェクトから check-acl SAF を削除することによって、パフォーマンスを向上させることができます。

メモリー不足の状況

Web Server をメモリー不足の状況で実行する必要がある場合は、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブで「最大スレッド数」の設定値を小さくすることによって、スレッドの制限を最低まで下げます。また、wadm set-thread-pool-prop コマンドの max-threads プロパティーを使用してこの値を設定することもできます。

高負荷の下で Web アプリケーションを実行していると、サーバーが Java VM ランタイムヒープスペース不足に陥る場合があります。この状態は、サーバーログファイル内の java.lang.OutOfMemoryError メッセージで示されます。この原因は、オブジェクトの過剰な割り当てなど、いくつか考えられますが、このような動作がパフォーマンスに影響を与える可能性があります。この問題に対処するには、アプリケーションのプロファイルを作成します。アプリケーションの割り当て (オブジェクトやそのサイズ) のプロファイリングに関する注意事項については、次の HotSpot VM のパフォーマンス FAQ を参照してください。

http://java.sun.com/docs/hotspot/index.html

場合によっては、アプリケーションが最大セッション数を使い切り (サーバーログファイル内の「too many active sessions」のメッセージで示される)、そのためコンテナが例外をスローすることで、さらにアプリケーションパフォーマンスに影響を与えることがあります。この状況に対処するには、セッションマネージャーのプロパティー、セッション作成アクティビティー (JSP のセッションはデフォルトで有効になることに注意)、およびセッションのアイドル時間を検討する必要があります。

少なすぎるスレッド

サーバーでは、アクティブなスレッドの数がスレッドの制限値を超えることは許可されません。同時要求の数がその制限に達すると、サーバーは、古い接続が解放されるまで新しい接続へのサービスを停止します。これによって、応答時間が増加する場合があります。

Web Server では、サーバーの最大スレッド数のデフォルト設定は 128 です。サーバーにより多くの要求を同時に処理させる場合は、スレッドの最大数を増やしてください。

サーバーのスレッドが少なすぎる場合の症状は、長い応答時間です。ブラウザから要求を発行するとサーバーへの接続はかなりすばやく確立されますが、サーバーに存在するスレッドが少なすぎる場合は、応答がクライアントに戻ってくるまでに長い時間がかかる可能性があります。

スレッドが少なすぎるためにサーバーが減速しているかどうかを検出するための最適な方法は、アクティブなセッションの数がスレッドの最大数に近いか、または等しくなっているかどうかを調べることです。これを実行するには、「セッション作成 (スレッド) 情報」を参照してください。

キャッシュが活用されていない

ファイルキャッシュが活用されていない場合は、サーバーが最適に実行されていません。ほとんどのサイトには、常にキャッシュ可能であるはずの多数の GIF または JPEG ファイルが存在するため、キャッシュを効率的に使用する必要があります。

ただし、サイトによっては、ほぼすべての処理を CGI、SHTML、またはその他の動的なソースによって実行している場合があります。一般に、動的コンテンツはキャッシュ可能ではないため、本質的にキャッシュヒット率は低くなります。サイトのキャッシュヒット率が低い場合でも、それほど心配する必要はありません。もっとも重要な点は、応答時間が短いことです。キャッシュヒット率が非常に低くても、応答時間は依然として非常に良好な場合があります。応答時間が良好であるかぎり、キャッシュヒット率が低いことを心配する必要はありません。

perfdump、管理コンソールの「監視」タブ、または wadm stats コマンドからの統計情報を使用して、ヒット率をチェックしてください。ヒット率は、キャッシュが使用された回数の、サーバーへのすべてのヒットに対するパーセンテージです。50% を超えていれば、キャッシュヒット率は良好です。サイトによっては、98% 以上を達成している場合もあります。詳細については、「ファイルキャッシュ情報 (静的コンテンツ)」を参照してください。

さらに、多数の CGI または NSAPI 呼び出しを実行している場合、キャッシュヒット率が低くなる可能性があります。また、カスタム NSAPI 関数を使用している場合も、キャッシュヒット率が低くなる可能性があります。

キープアライブ接続がフラッシュされる

キープアライブ接続なしで 1 秒あたり 75 の要求を処理できる可能性のある Web サイトは、キープアライブを有効にすると、1 秒あたり 200 〜 300 の要求を処理できる可能性があります。そのため、クライアントが 1 つのページにさまざまな項目を要求する場合は、キープアライブ接続が効率的に使用されていることが重要です。perfdump で示される KeepAliveCount (管理コンソールに表示される「追加した接続の合計数」) がキープアライブ最大接続数を超えると、以降のキープアライブ接続は、キープアライブの状態を維持されずに閉じられます (「フラッシュされる」)。

perfdump からの統計情報を使用して KeepAliveFlushes および KeepAliveHits 値をチェックするか、または「監視統計」ページの「キープアライブ統計」の下にある「フラッシュした接続の数」と「処理した接続の数」をチェックしてください。詳細については、「キープアライブ情報」を参照してください。

キープアライブ接続が適切に実行されているサイトでは、KeepAliveFlushes と KeepAliveHits の比率は非常に低くなります。この比率が (1:1 より) 高い場合、そのサイトではおそらく、キープアライブ接続が期待されるほどは適切に活用されていません。

キープアライブのフラッシュを削減するには、キープアライブ最大接続数 (構成の「パフォーマンス」タブ ⇒「HTTP」サブタブ、または wadm set-keep-ailve props コマンドで設定される) を増やしてください。デフォルト値は 200 です。この値を増やすことによって、より多くの待機中のキープアライブ接続が開いたままになります。

UNIX/Linux システムでは、キープアライブ最大接続数の値が大きすぎると、サーバーのオープンファイル記述子が不足する場合があります。一般に、UNIX/Linux では 1024 が開かれたファイルの制限であるため、この値を 500 を超えて増やすことはお勧めできません。

ログファイルモード

ログファイルを高い冗長レベルに維持すると、パフォーマンスに大きな影響を与える可能性があります。構成の「一般」タブ ⇒「ログ設定」ページで、適切なログレベルを選択し、「詳細」、「より詳細」、および「もっとも詳細」などのレベルを慎重に使用してください。CLI を使用してログレベルを設定するには、コマンド wadm set-log-prop を使用し、log-level を設定します。