test

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

第 2 章 Sun Java System Web Server のチューニング

この章では、Sun Java System Web Server のパフォーマンス改善のために実施可能な具体的な調整について説明します。チューニング設定に関する理解を深められるよう、Web Server の接続処理プロセスの概要について説明します。この章の内容は、次のとおりです。

注 –

サーバーのチューニング時には細心の注意を払うようにしてください。変更を加える前に必ず、構成ファイルのバックアップを作成します。

一般的なチューニングのヒント

サーバーをチューニングする際には、ユーザー固有の環境は一意であることを忘れないことが重要です。このガイドに含まれる提案の影響は、ユーザー固有の環境に応じて異なります。最終的には、自身の判断や観察に基づいて最適な調整を選択する必要があります。

パフォーマンスの最適化作業を行う際には、次の指針を参考にしてください。

スレッド、プロセス、および接続の理解

サーバーをチューニングする前に、Web Server の接続処理プロセスを理解しておくべきです。この節では、次の内容について説明します。

接続処理の概要

Web Server では、待機ソケット上のアクセプタスレッドが接続を受け付け、それらを接続キューに入れます。次に、スレッドプール内の要求処理スレッドがキューから接続を取り出し、その要求を処理します。

図 2–1 Web Server の接続処理

要求がどのようにして要求処理スレッドに送信されるかを示す、Web Server での接続処理。

また、別のスレッドプールに要求を送信して処理を依頼するように、要求処理スレッドに指示することもできます。たとえば、要求処理スレッドがスレッドに対して安全でないある作業を実行する必要がある場合、その処理の一部を NativePool に送信するように指示することができます。NativePool は作業が完了すると、その結果を要求処理スレッドに伝え、要求処理スレッドが要求の処理を続行します。

サーバーの起動時に作成されるのは、スレッドプールの最小スレッド数に定義された数のスレッドだけであり、これはデフォルトで 16 個です。負荷が増えるとサーバーによって追加のスレッドが作成されます。新しいスレッドの追加ポリシーは、接続キューの状態に基づいています。

新しい接続が返されるたびに、キュー内で待機している接続の数 (接続のバックログ) が、すでに作成された要求処理スレッドの数と比較されます。待機している接続の数がスレッド数を上回った場合、次回の要求完了時に新しいスレッドが追加されるようにスケジュールされます。

新しいセッションスレッドの追加プロセスは、最大スレッド数の値に厳密に制限されます。最大スレッド数の詳細については、「最大スレッド数 (最大同時要求数)」を参照してください。

スレッド、プロセス、および接続の数やタイムアウトに影響を与える設定を変更するには、管理コンソールで、構成の「パフォーマンス」タブ (HTTP 設定) および「HTTP リスナー」タブを使用します。また、wadm コマンド set-thread-pool-prop、set-http-listener-prop、および set-keep-alive-prop を使用することもできます。

短待ち時間モードと高並行性モード

サーバーは、負荷に応じて 2 つのモードのいずれかで稼働できます。負荷の増減にもっとも効率的に対応できるようにモードを切り替えます。

サーバーの起動時には、短待ち時間モードが使用されます。負荷が増えると、サーバーは高並行性モードに移行します。短待ち時間モードから高並行性モードに移行したり、元の短待ち時間モードに戻ったりする判断は、接続キューの長さ、平均セッション合計数、平均アイドルセッション数、および現在のアクティブセッション数とアイドルセッション数に基づいて、サーバーによって行われます。

無効化されたスレッドプール

スレッドプールが無効化されると、スレッドがプール内に作成されず、接続キューやキープアライブスレッドも作成されません。スレッドプールが無効になると、アクセプタスレッド自身が要求を処理します。

magnus.conf の NSAPI 向けの接続処理指令

前述した設定に加え、magnus.conf ファイル内で次の指令を編集すれば、NSAPI プラグイン向けの要求処理を追加で構成できます。

これらの指令の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』を参照してください。

注 –

magnus.conf などの構成ファイルを編集するためのもっとも安全な方法は、wadm コマンド get-config-file と set-config-file を使って編集用のローカルコピーを取得し、それを Web Server に戻すことです。これらのコマンドの詳細については、各コマンドのヘルプを参照してください。

カスタムスレッドプール

デフォルトでは、接続キューはデフォルトのスレッドプールに要求を送信します。ただし、magnus.conf 内でスレッドプールの Init 関数を使ってユーザー独自のスレッドプールを作成することもできます。これらのカスタムスレッドプールは、要求の全体を処理するためではなく、NSAPI サービスアプリケーション関数 (SAF) を実行するために使用されます。

SAF がカスタムスレッドプールの使用を必要とする場合、現在の要求処理スレッドは、要求をキューに入れ、カスタムスレッドプール内の別のスレッドがその SAF を完了するまで待機したあと、その要求の残りの部分を完了します。

たとえば、obj.conf ファイルの内容が次のようになっているとします。

NameTrans fn="assign-name" from="/testmod" name="testmod" pool="my-custom-pool"
...
<Object name="testmod">
ObjectType fn="force-type" type="magnus-internal/testmod"
Service method=(GET|HEAD|POST) type="magnus-internal/testmod"
fn="testmod_service" pool="my-custom-pool2"
</Object>

この例の場合、要求は次のように処理されます。

  1. 要求処理スレッド (この例では A1 と呼ぶ) が要求を取り出し、NameTrans 指令の前の手順を実行します。

  2. URI が /testmod で始まっている場合、A1 スレッドはその要求を my-custom-pool キューに入れます。A1 スレッドは待機します。

  3. my-custom-pool 内の別のスレッドをこの例では B1 スレッドと呼びますが、A1 によってキューに入れられた要求をその B1 が取り出します。B1 がこの要求の処理を完了し、待機段階に戻ります。

  4. A1 スレッドが呼び起こされ、その要求の処理を続行します。これは、ObjectType SAF を実行したあと、Service 関数に移ります。

  5. この Service 関数は my-custom-pool2 内のスレッドによって処理される必要があるため、A1 スレッドが要求を my-custom-pool2 キューに入れます。

  6. my-custom-pool2 内の別のスレッドをこの例では C1 と呼びますが、キューに入れられた要求をその C1 が取り出します。C1 がこの要求の処理を完了し、待機段階に戻ります。

  7. A1 スレッドが呼び起こされ、その要求の処理を続行します。

この例では、3 つのスレッド A1、B1、および C1 が動作して要求の処理を完了させます。

追加のスレッドプールは、スレッドに対して安全でないプラグインを実行するための手段の 1 つです。最大スレッド数が 1 に設定されたプールを定義すると、指定されたサービス関数内で 1 つの要求しか実行できなくなります。前述の例で testmod_service がスレッドに対して安全でない場合には、そのサービスを単一のスレッドを使って実行する必要があります。my-custom-pool2 内に単一のスレッドを作成すれば、この SAF がマルチスレッド化された Web Server 内で正常に動作するようになります。

スレッドプールの定義方法の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』の「thread-pool-init」を参照してください。

ネイティブスレッドプール

Windows 上では、実行にネイティブスレッドを必要とする NSAPI 関数を実行する目的で、ネイティブスレッドプール (NativePool) がサーバーによって内部的に使用されます。

Web Server は NSPR (Netscape Portable Runtime) を使用します。これは移植性を高めるための基盤層であり、ホスト OS のサービスへのアクセス機能を提供します。この層はスレッドの抽象化を提供しますが、それは必ずしも、OS が提供するスレッドに対する抽象化と同一であるとは限りません。これらの非ネイティブスレッドのスケジューリングオーバーヘッドは比較的低いので、それらを使用すればパフォーマンスを改善できます。ただし、これらのスレッドは、入出力呼び出しなど、OS に対するブロック呼び出しの影響を受けやすい性質を持っています。ブロック呼び出しを使用する可能性のある NSAPI 拡張の記述を容易にするために、サーバーはブロック呼び出しを安全にサポートするスレッドのプールを保持します。これらのスレッドは通常、ネイティブ OS スレッドになります。要求の処理中に、非ネイティブスレッド上で安全に実行できる関数としてマークされていない NSAPI 関数はすべて、ネイティブスレッドプール内のいずれかのスレッド上で実行されるようにスケジュールされます。

ユーザーが NameTrans、Service、PathCheck 関数など、独自の NSAPI プラグインを記述した場合、それらの関数はデフォルトで、ネイティブスレッドプール内のスレッド上で実行されます。プラグインが NSAPI 関数を入出力のためだけに使用しているか、あるいは NSAPI 入出力関数をまったく使用していない場合、そのプラグインは非ネイティブスレッド上で実行できます。そのためには、その関数の読み込み時に NativeThread="no" オプションを指定し、ネイティブスレッドを必要としないことを示す必要があります。

たとえば、magnus.conf ファイル内の load-modules Init 行に、次のコードを追加します。

Init funcs="pcheck_uri_clean_fixed_init" shlib="C:/Sun/webserver7/lib/custom.dll" 
fn="load-modules" NativeThread="no"

NativeThread フラグは funcs リスト内のすべての関数に影響を与えます。したがって、ライブラリ内に関数が 2 つ以上存在しているが、ネイティブスレッドを使用するのはその一部だけである場合には、複数の Init 行を使用してください。NativeThread を yes に設定すると、スレッドは直接 OS スレッドにマップされます。

load-modules 関数については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』の「load-modules」を参照してください。

プロセスのモード

注 –

マルチプロセスモードは非推奨です。したがって、次の各節の情報は、下位互換性を維持するためだけに含まれています。マルチプロセスモードが非推奨になっているのは、今日では大部分のアプリケーションがマルチスレッド化されており、マルチプロセスモードは通常、必要とされないからです。

Sun Java System Web Server は、次の 2 つのモードのいずれかで実行できます。

シングルプロセスモード

シングルプロセスモードでは、サーバーは Web クライアントからの要求を単一のプロセスを使って受信します。単一サーバープロセスの内側ではアクセプタスレッドが実行されており、新しい要求が到着するのを待っています。要求が到着すると、アクセプタスレッドが接続を受け付け、その要求を接続キューに入れます。要求処理スレッドが接続キューから要求を取り出し、その要求を処理します。

サーバーはマルチスレッド化されているため、サーバー用に記述された NSAPI 拡張はすべて、スレッドに対して安全でなければいけません。つまり、NSAPI 拡張がファイルへの共有参照やグローバル変数など、あるグローバルリソースを使用している場合には、一度に 1 つのスレッドしかそのリソースにアクセスしないように、そのリソースの使用を同期させる必要があります。Web Server に付属するプラグインはすべて、スレッドに対して安全であり、かつスレッドを認識するため、高いスケーラビリティーと並行性を実現できます。これに対し、旧バージョンのアプリケーションはシングルスレッドである可能性があります。サーバーがそうしたアプリケーションを実行する場合、一度に 1 つしか実行できません。このため、高負荷下ではサーバーパフォーマンスの問題が発生します。残念ながら、シングルプロセスの設計では、現実的な回避方法は存在しません。

マルチプロセスモード

複数のプロセスと各プロセス内の複数のスレッドを使って要求を処理するように、サーバーを構成することができます。この柔軟性により、スレッドを使用するサイトで最適なパフォーマンスを実現できるだけでなく、スレッド化された環境内で実行する準備が整っていない旧バージョンのアプリケーションを実行するサイトで、下位互換性を維持することができます。Windows 上のアプリケーションは一般に、すでにマルチスレッドを活用しているため、この機能は UNIX および Linux プラットフォームに適用されます。

マルチプロセスの利点は、スレッドを認識しないかスレッドに対して安全でない旧バージョンのアプリケーションを、Sun Java System Web Server 内でより効果的に実行できるという点です。ただし、Sun Java System 拡張はどれもシングルプロセスのスレッド化環境をサポートするように構築されているため、それらの拡張がマルチプロセスモードでは動作しない可能性があります。サーバーがマルチプロセスモードになっていると検索プラグインの起動が失敗し、セッションレプリケーションが有効になっていると、マルチプロセスモードでのサーバーの起動が失敗します。

マルチプロセスモードの場合、サーバーは起動時に、複数のサーバープロセスを生成します。各プロセスには、受信要求を受け取るためのスレッドが、構成に応じて 1 つ以上含まれます。各プロセスは完全に独立しているため、グローバル変数、キャッシュ、およびその他のリソースの独自のコピーを持ちます。複数のプロセスを使用する場合、多くのリソースがシステムに必要です。また、共有状態を必要とするアプリケーションのインストールを試みる場合、そのアプリケーションは複数のプロセス間でその状態の同期を取る必要があります。NSAPI には、プロセス間の同期を実装するためのヘルパー機能は用意されていません。

MaxProcs 値として 1 より大きい値を指定すると、サーバーは、複数のサーバープロセス間で接続を分散する処理をオペレーティングシステムに依頼します (MaxProcs 指令については「MaxProcs (UNIX/Linux)」を参照)。ただし、最近のオペレーティングシステムの多くは、同時接続数が少ない場合は特に、接続を均等に分散しません。

Sun Java System Web Server はサーバープロセス間での均等な負荷分散を保証できないため、スレッドに対して安全でない旧バージョンのアプリケーションに対応するために「最大スレッド数」を 1 に、MaxProcs を 1 より大きい値にそれぞれ設定すると、パフォーマンスの問題が発生する可能性があります。旧バージョンのアプリケーションにバックエンドデータベースが含まれている場合など、旧バージョンのアプリケーションが要求に応答するまでに長い時間がかかる場合には特に、この問題が顕著になります。このシナリオではおそらく、「最大スレッド数」にデフォルト値を使用し、旧バージョンのアプリケーションへのアクセスをスレッドプールを使って直列化するのが適切です。スレッドプールの作成方法の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』の「thread-pool-init」を参照してください。

サーバー内で NSAPI を 1 つも実行しない場合には、次のデフォルト設定を使用するべきです。1 つのプロセスと多数のスレッド。スレッド化された環境内でのスケーラビリティーを持たないアプリケーションを実行する場合には、少数のプロセスと多数のスレッド、具体的には 4 個または 8 個のプロセスと、1 プロセスあたり 128 個または 512 個のスレッドなどを使用するべきです。

MaxProcs (UNIX/Linux)

注 –

MaxProcs は非推奨であり、下位互換性を維持するためだけに含まれています。

UNIX/Linux サーバーをマルチプロセスモードに設定するには、この指令を使用します。このモードを使えば、マルチプロセッサマシン上でのスケーラビリティーが向上する可能性があります。これを 1 より小さい値に設定すると、その値は無視され、デフォルト値の 1 が使用されます。

MaxProcs の値を設定するには、magnus.conf 内の MaxProcs パラメータを編集します。

注 –

サーバーを MaxProcs モードで実行すると、起動メッセージが重複して表示されます。

Web Server 6.1 チューニングパラメータから Web Server 7.0 へのマッピング

Web Server 6.1 で magnus.conf および nsfc.conf ファイルを編集してチューニング可能だったチューニングパラメータの多くは、server.xml ファイルに移されました。これらのチューニングパラメータは、管理コンソールとコマンド行インタフェースを使ってチューニング可能になりました。次の表では、いくつかのチューニングパラメータについて、Web Server 6.1 パラメータ、チューニングに使用する新しい server.xml の要素、およびユーザーインタフェース経由でのパラメータの変更方法を示します。server.xml ファイルを直接編集すると間違いが起こりやすいので、ユーザーインタフェースを使って値を設定することをお勧めします。server.xml のすべての要素の完全なリストについては、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』の第 3 章「Elements in server.xml」を参照してください。

表 2–1 server.xml へのパラメータマッピング

Web Server 6.1 のパラメータ 

Web Server 7.0 の server.xml の要素または属性

管理コンソールの場所 

wadm コマンド

magnus.conf の AcceptTimeout

http 要素の io-timeout 要素

構成の「パフォーマンス」タブ ⇒「HTTP 設定」ページ 

set-http-prop コマンドの io-timeout プロパティー

magnus.conf の ACLGroupCacheSize

acl-cache 要素の max-groups-per-user 要素

構成の「パフォーマンス」タブ ⇒「キャッシュ設定」ページ 

set-acl-cache-prop コマンドの max-groups-per-user プロパティー

magnus.conf の ACLUserCacheSize

acl-cache 要素の max-users 要素

構成の「パフォーマンス」タブ ⇒「キャッシュ設定」ページ 

set-acl-cache-prop コマンドの max-users プロパティー

magnus.conf の ConnQueueSize

thread-pool 要素の queue-size 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-thread-pool-prop コマンドの queue-size プロパティー

dns-cache-init Init SAF

dns-cache 要素の enabled 要素

構成の「パフォーマンス」タブ ⇒「DNS」タブ 

set-dns-cache-prop コマンドの enabled プロパティー

dns-cache-init Init SAF のキャッシュサイズ

dns-cache 要素の max-entries 要素

構成の「パフォーマンス」タブ ⇒「DNS」タブ 

set-dns-cache-prop コマンドの max-entries プロパティー

nsfc.conf の FileCacheEnabled

file-cache 要素の enabled 要素

構成の「パフォーマンス」タブ ⇒「キャッシュ」タブ 

set-file-cache-prop コマンドの enabled プロパティー

magnus.conf の KeepAliveThreads

keep-alive 要素の threads 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-keep-alive-prop コマンドの threads プロパティー

magnus.conf の KeepAliveTimeout

keep-alive 要素の timout 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-keep-alive-prop コマンドの timeout プロパティー

magnus.conf の KernelThreads (Windows のみ)

変更なし 

   

magnus.conf の ListenQ

http-listener 要素の listen-queue-size 要素

構成の「HTTP リスナー」タブ 

set-http-listener-prop コマンドの listen-queue-size

magnus.conf の LogVerbose

log 要素の log-level 要素

構成の「一般」タブ ⇒「ログ設定」 

set-error-log-prop コマンドの log-level プロパティー

nsfc.conf ファイルの MaxAge

file-cache 要素の max-age 要素

構成の「パフォーマンス」タブ ⇒「キャッシュ」タブ 

set-file-cache-prop コマンドの max-age プロパティー

nsfc.conf ファイルの MaxFiles

file-cache 要素の max-entries 要素

構成の「パフォーマンス」タブ ⇒「キャッシュ」タブ 

set-file-cache-prop コマンドの max-entries プロパティー

magnus.conf の MaxKeepAliveConnections

keep-alive 要素の max-connections 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-keep-alive-prop コマンドの max-connections プロパティー

magnus.conf の MaxProcs

非推奨 

   

magnus.conf の NativePoolMaxThreads

変更なし 

   

magnus.conf の NativePoolMinThreads

変更なし 

   

magnus.conf の NativePoolQueueSize

変更なし 

   

magnus.conf の NativePoolStackSize

変更なし 

   

magnus.conf の RqThrottle

thread-pool 要素の max-threads 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-thread-pool-prop コマンドの max-threads プロパティー

magnus.conf の RqThrottleMin

thread-pool 要素の min-threads 要素

構成の「パフォーマンス」タブ ⇒「HTTP」タブ 

set-thread-pool-prop コマンドの min-threads プロパティー

magnus.conf の TerminateTimeout

変更なし 

   

監視データに基づくサーバーのチューニング

この節では、管理コンソール、perfdump、コマンド行インタフェース、および stats-xml 経由で利用可能なパフォーマンス情報について説明します。ここでは、その情報を解析して一部のパラメータをチューニングすることで、サーバーのパフォーマンスを改善する方法について説明します。

デフォルトのチューニングパラメータはほとんどすべてのサイトに適していますが、扱うボリュームが非常に大きいサイトだけは例外です。大規模サイトでおそらく定期的に変更する必要のある設定は、スレッドプールとキープアライブの設定だけです。これらの設定を構成レベルでチューニングするには、管理コンソール、wadm コマンドのいずれかを使用します。server.xml ファイル内の要素を直接編集することでサーバーをチューニングすることも可能ですが、server.xml ファイルを直接編集すると作業が煩雑になる可能性があります。

perfdump は次のカテゴリの統計を監視しますが、これらの各カテゴリについては次の各節で説明します。ほとんどの場合、これらの統計は管理コンソール、コマンド行インタフェース、および stats-xml 出力にも表示されます。次の各節には、どの方法を使ってデータを監視するかにかかわらず、これらすべてのカテゴリのチューニング情報が含まれています。

これに加え、管理コンソール、コマンド行インタフェース、および stats-xml 経由で表示される統計情報には、perfdump の出力に含まれない別のカテゴリも含まれています。それらの統計をチューニングする方法については、次の各節で説明します。

必要な統計を表示し終わったら、管理コンソールの「パフォーマンス」タブを使用することで、サーバーのパフォーマンスに関するさまざまな側面を構成レベルでチューニングできます。管理コンソールの「パフォーマンス」タブには、次のような多数のパフォーマンスカテゴリの設定が含まれています。

また、適切な wadm コマンドを使用することによっても、チューニングパラメータの表示や設定を行えます。一般に、wadm コマンドを使ってチューニングプロパティーを設定する場合、そのプロパティーの名前は stats.xml に表示されるものと同じになります。

接続キュー情報

Web Server では、接続はまず、HTTP リスナーに関連付けられたアクセプタスレッドによって受け付けられます。アクセプタスレッドが接続を受け付け、それを接続キューに入れます。次に、要求処理スレッドが接続キュー内の接続を取り出し、その要求を処理します。詳細については、「接続処理の概要」を参照してください。

接続キュー情報には、接続キュー内のセッション数と、接続が要求処理スレッドによって受け付けられるまでの平均遅延が表示されます。

次に、perfdump でのそれらの統計の表示例を示します。

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/1853/160032
Total Connections Queued                   11222922
Average Queue Length (1, 5, 15 minutes)    90.35, 89.64, 54.02
Average Queueing Delay                     4.80 milliseconds

管理コンソールまたはコマンド行インタフェースではこれと同じ情報が異なる形式で表示されます。ただし、若干の相違はあります。次の表に、管理コンソールでサーバーインスタンスの監視情報にアクセスした際に表示される情報を示します。

表 2–2 接続キューの統計

現在の待機接続の数 

0 

待機接続の合計数 

11222922 

最近 1 分の平均接続数 

90.35 

最近 5 分の平均接続数 

89.64 

最近 15 分の平均接続数 

54.02 

最大キューサイズ 

160032 

最大キューサイズ 

1853 

オーバーフロー接続の数 

0 

消費したティック 

5389284274 

追加した接続の合計数 

425723 

現在/ピーク/制限のキュー長

Current/Peak/Limit queue length には、次の情報が順に表示されます。

チューニング

ピークキュー長 (最大キューサイズ) が制限に近くなった場合には、最大接続キューサイズを増やすことで、高負荷時に接続が無視されるのを回避できます。

管理コンソールで最大接続キューサイズを増やすには、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブにある、スレッドプールの「キューサイズ」フィールドの値を変更します。デフォルトは 1024 です。

コマンド行インタフェースを使ってキューサイズを変更するには、wadm set-thread-pool-prop コマンドの queue-size プロパティーを使用します。

待機接続の合計数

Total Connections Queued は、これまで接続がキューに入れられた回数の合計値です。この数値には、新しく受け付けられた接続と、キープアライブシステムからの接続が含まれます。

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

平均キュー長

Average Queue Length には、直前の 1 分間、5 分間、および 15 分間におけるキュー内の平均接続数が表示されます。

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

平均キュー遅延

Average Queueing Delay は、接続が接続キュー内で費やす時間の平均値です。これは、ある要求の接続がサーバーによって受け付けられてから、要求処理スレッドがその要求の処理を開始するまでの遅延を表します。これは、「消費したティック」を「待機接続の合計数」で割った結果をミリ秒に変換したものになります。

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

消費したティック

ティックはシステムに依存する値であり、stats.xml 内の server 要素の tickPerSecond 属性によって提供されます。消費したティックの値は、接続が接続キュー内で費やした時間の合計であり、平均キュー遅延を計算するために使用されます。

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

追加した接続の合計数

接続キューに追加された新しい接続の数。この設定はチューニング不可能です。

HTTP リスナー (待機ソケット) 情報

次の HTTP リスナー情報には、IP アドレス、ポート番号、アクセプタスレッドの数、およびデフォルト仮想サーバーが含まれています。この HTTP リスナー情報の中で、チューニングのためにもっとも重要なフィールドは、アクセプタスレッドの数です。

仮想サーバーに対して多数の HTTP リスナーを有効にすることができますが、デフォルトサーバーインスタンスでは少なくとも 1 つのリスナー (通常は http://0.0.0.0:80) が有効になります。管理コンソール経由で利用可能な監視情報には、HTTP リスナー情報が表示されません。なぜなら、管理コンソールでは、その情報は構成の「HTTP リスナー」タブで利用可能になっているからです。

次に、perfdump での HTTP リスナー情報の表示例を示します。

ListenSocket ls1:
------------------------
Address                   https://0.0.0.0:2014
Acceptor Threads          1
Default Virtual Server    https-test

HTTP リスナーを複数個作成した場合、perfdump にはそれらがすべて表示されます。

管理コンソールを使って HTTP リスナーを編集するには、使用する構成で「HTTP リスナー」タブを選択します。リスナーの名前をクリックしてそのリスナーを編集します。

コマンド行インタフェースを使って HTTP リスナーを構成するには、コマンド wadm set-http-listener-prop を使用します。

待機ソケットを追加および編集する方法の詳細については、『Sun Java System Web Server 7.0 管理ガイド』を参照してください。

アドレス

Address フィールドには、この待機ソケットが待機する基底アドレスが含まれます。1 つのホストが複数のネットワークインタフェースと複数の IP アドレスを持つ可能性があります。アドレスには IP アドレスとポート番号が含まれます。

ホストマシンのすべてのネットワークインタフェース上で待機ソケットが待機する場合、アドレスの IP 部分は 0.0.0.0 になります。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。0.0.0.0 以外の IP アドレスを指定すると、サーバーが接続ごとに行うシステムコールの数が、1 つだけ少なくなります。実現可能な最高のパフォーマンスが得られるよう、0.0.0.0 以外の IP アドレスを指定してください。

アクセプタスレッド

アクセプタスレッドは、接続を待機するスレッドです。それらのスレッドが接続を受け付けてキューに入れたあと、ワークスレッドがそれらの接続を取り出します。詳細については、「接続処理の概要」を参照してください。

ユーザーからの要求があったときにいつでも対応できるように、常に十分な数のアクセプタスレッドを用意しておくのが理想的ですが、システムに負荷がかかり過ぎない数に抑える必要もあります。推奨の規則は、システム上の CPU ごとにアクセプタスレッドを 1 つずつ用意することです。TCP/IP 待機キューのオーバーランが発生する場合には、この値を CPU 数の約 2 倍に増やすことができます。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。デフォルトは 1 です。

パフォーマンスに影響を与えるその他の HTTP リスナー設定は、送信バッファーと受信バッファーのサイズです。これらのバッファーの詳細については、使用しているオペレーティングシステムのマニュアルを参照してください。

デフォルト仮想サーバー

仮想サーバーは、HTTP 1.1 の Host ヘッダーを使って動作します。エンドユーザーのブラウザが Host ヘッダーを送信しなかった場合や、サーバーが Host ヘッダーに指定された仮想サーバーを見つけられなかった場合、Web Server はデフォルト仮想サーバーを使って要求を処理します。エラーメッセージを送信したり、特殊なドキュメントルートからのページを提供したりするように、デフォルト仮想サーバーを構成することができます。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。

キープアライブ情報

このセクションでは、サーバーの 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>

セッション作成 (スレッド) 情報

セッション (スレッド) 作成の統計は、perfdump では次のように表示されます。

SessionCreationInfo:
------------------------
Active Sessions           128
Keep-Alive Sessions       0
Total Sessions Created    128/128

Active Sessions は、現在要求を処理しているセッションの数 (要求処理のスレッド) を示しています。

Keep-Alive Sessions には、キープアライブセッションを処理する HTTP 要求処理スレッドの数が表示されます。

perfdump の Total Sessions Created には、作成されたセッションの数と最大スレッド数が表示されます。

管理コンソールでこれに相当する情報である「スレッドの合計数」は、「監視」タブ ⇒「インスタンス」サブタブの「一般統計」の下で利用可能になっています。許容される最大のスレッド数を表示するには、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブの、「スレッドプール設定」の下にある「最大スレッド数」フィールドを参照してください。

perfdump の Active Sessions に相当する情報を得るには、「スレッドの合計数」から「アイドルスレッドの数」を引きます。

最大スレッド数 (最大同時要求数)

最大スレッド数の設定は、Web Server が処理できる同時トランザクションの最大数を指定します。デフォルト値は 128 です。この値を変更するとサーバーのパフォーマンスを調整でき、実行されるトランザクションの待ち時間を最小限に抑えることができます。「最大スレッド数」の値は複数の仮想サーバーにまたがって適用されますが、その際に負荷分散が試みられることはありません。これは構成ごとに設定されます。

設定されたスレッドの最大数に達してしまってもかまいません。また、サーバーのスレッド数を反射的に増やす必要もありません。この最大限度に達したということは、サーバーがピークロード時にこれだけの数のスレッドを必要としたことを意味しています。しかし、要求がタイムリーに処理されているかぎり、サーバーは適切にチューニングされているといえます。ただし、この時点で接続は接続キューに入れられるため、オーバーフローする可能性もあります。サーバーのパフォーマンスを定期的に監視し、作成されたセッションの合計数が最大スレッド数に近くなることが多いようであれば、スレッドの上限を増やすことを検討するべきです。

同時処理する要求数を計算するために、サーバーはアクティブな要求数をカウントし、そこに新しい要求が届いたら 1 を足し、要求が終了したら 1 を引きます。新しい要求が到着すると、サーバーは処理中の要求がすでに最大数に達しているかどうかをチェックします。上限に達していた場合、サーバーは、アクティブな要求の数がその最大量を下回るまで、新しい要求の処理を遅らせます。

理論上は、最大スレッド数を 1 に設定しても、サーバーは正常に機能します。この値を 1 に設定することは、サーバーが一度に処理できる要求が 1 つだけであることを意味しますが、静的ファイルの HTTP 要求の処理時間は一般に非常に短い (応答時間はわずか 5 ミリ秒程度である可能性がある) ため、一度に 1 つの要求を処理したとしても、1 秒間に最大 200 件の要求を処理できることになります。

ただし、実際には、インターネットクライアントがサーバーに接続したあと、要求を完了しないことが頻繁に発生します。そうした場合には、サーバーはデータの到着を 30 秒またはそれ以上待ったあと、タイムアウトを発生させます。このタイムアウト時間を定義するには、構成の「パフォーマンス」タブ ⇒「HTTP 設定」ページの「入出力タイムアウト」設定を使用します。また、コマンド wadm set-http-prop を使って io-timeout プロパティーを設定することもできます。デフォルトは 30 秒です。これをデフォルトより小さい値に設定すれば、スレッドがより早く解放されるようになりますが、一方で低速な接続のユーザーを切断する可能性も出てきます。また、一部のサイトでは、完了までに数分かかる高負荷のトランザクションが実行されます。これらの要因はどちらも、必要とされる最大同時要求数を増加させます。多くの秒数のかかる要求を多数処理するサイトでは、最大同時要求数を増やさなければいけない可能性があります。

適切な最大スレッド値の範囲は、負荷によって 100 〜 500 になります。「最大スレッド数」は同時に実行可能なアクティブスレッドの最大数に対する強い制限値を表しますが、これがパフォーマンス上の障害になる可能性があります。デフォルト値は 128 です。

スレッドプールの最小スレッド数は、サーバーが起動時に開始するスレッドの最小数です。デフォルト値は 16 です。

注 –

SNCA (Solaris Network Cache and Accelerator) と組み合わせて使用するように Web Server を構成する場合、最大スレッド数とキューサイズを 0 に設定するとパフォーマンスが改善されます。SNCA がクライアント接続を管理するので、これらのパラメータを設定する必要はありません。SNCA を使用しない構成でも、これらのパラメータを 0 に設定できます。キープアライブを使用しないで待ち時間の短い応答を配信する必要がある場合は特にそうです。最大スレッド数とキューサイズの「両方」を 0 に設定する必要があることに注意してください。

SNCA の使用方法については、「Solaris Network Cache and Accelerator (SNCA) の使用」を参照してください。

チューニング

管理コンソールでスレッドの上限を増やすには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「スレッドプール設定」の下にある「最大スレッド数」フィールドを編集します。コマンド行インタフェースでは、wadm set-thread-pool-prop コマンドの max-threads プロパティーを使用します。デフォルトは 128 です。

ファイルキャッシュ情報 (静的コンテンツ)

キャッシュ情報セクションは、ファイルキャッシュがどのように使用されているかに関する統計を提供します。ファイルキャッシュには静的コンテンツが書き込まれるため、サーバーは静的コンテンツに対する要求をすばやく処理できます。ファイルキャッシュには、ファイルに関する情報と静的なファイルコンテンツが保存されます。ファイルキャッシュでは、サーバーにより解析される HTML の処理の高速化に使用される情報もキャッシュに書き込まれます。サーブレットや JSP では、別の種類のキャッシュが使用されます。

コンテンツへの更新がスケジュールに従って行われるサイトでは、コンテンツの更新中はキャッシュを停止し、更新完了後にキャッシュを再度起動することを検討してください。キャッシュを無効にすると、パフォーマンスは低下しますが、サーバーは正常に動作します。

パフォーマンス上の理由により、Web Server はキャッシュへの書き込みを次のように行います。

次に、perfdump でのキャッシュ統計の表示例を示します。

CacheInfo:
------------------
enabled             yes
CacheEntries        12/1024
Hit Ratio           46/98 ( 46.94%)
Maximum Age         30

次の表に、管理コンソールで表示されるファイルキャッシュ統計を示します。

表 2–4 ファイルキャッシュ統計

キャッシュヒットの合計 

46 

キャッシュミスの合計 

52 

キャッシュコンテンツヒットの合計 

0 

ファイル検索エラーの数 

9 

ファイル情報検索の数 

37 

ファイル情報検索エラーの数 

50 

エントリ数 

12 

最大キャッシュサイズ 

1024 

オープンファイルエントリの数 

0 

許可されている最大オープンファイル数 

1024 

ヒープサイズ (Heap Size) 

36064 

最大ヒープキャッシュサイズ 

10735636 

メモリーマップファイルコンテンツのサイズ 

0 

最大メモリーマップファイルサイズ 

0 

エントリの最大継続時間 

30 

有効

キャッシュが無効になっていると、このセクションの残りの部分が perdump で表示されません。管理コンソールでは、「ファイルキャッシュ統計」セクションの値としてゼロが表示されます。

チューニング

キャッシュはデフォルトで有効になっています。管理コンソールでこれを無効にするには、構成の「パフォーマンス」タブ ⇒「キャッシュ」サブタブの「ファイルキャッシュ」の下にある、「ファイルキャッシュ」の「有効」ボックスの選択を解除します。コマンド行インタフェースでこれを無効にするには、wadm set-file-cache-prop を使って enabled プロパティーを false に設定します。

キャッシュエントリ数

キャッシュエントリの現在の数と最大数の両方が、perfdump に表示されます。管理コンソールでは、それらは「エントリ数」および「最大キャッシュサイズ」と呼ばれます。単一のキャッシュエントリは単一の URI を表します。

チューニング

管理コンソールでキャッシュエントリの最大数を設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大エントリ数」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-entries プロパティーを設定します。デフォルトは 1024 です。値の範囲は 1 〜 1048576 です。

ヒット率 (キャッシュヒット数 / キャッシュ検索数)

perfdump 経由で利用可能なヒット率は、キャッシュ検索数に対するファイルキャッシュヒット数です。100% に近い数値が、ファイルキャッシュが効果的に機能していることを示しているのに対し、0% に近い数値は、ファイルキャッシュがあまり多くの要求を処理できていないことを示している可能性があります。

管理コンソール経由で提供される統計に基づいてこの数値を手動で計算するには、「キャッシュヒットの合計」と「キャッシュミスの合計」を足したもので、「キャッシュヒットの合計」を割ります。

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

最大継続時間

このフィールドには、有効なキャッシュエントリの最大継続時間が表示されます。このパラメータは、ファイルがキャッシュに書き込まれたあと、そのキャッシュ情報がどのくらいの期間使用されるかを制御します。最大継続時間を経過したエントリは、同じファイルの新しいエントリで置き換えられます。

チューニング

コンテンツを定期的に更新 (既存のファイルを変更) するかどうかに基づいて最大時間を設定します。たとえば、コンテンツが定期的に 1 日に 4 回更新される場合、最大時間を 21600 秒 (6 時間) に設定できます。それ以外の場合、最大時間には、ファイルが変更されたあと、以前のバージョンのコンテンツファイルを提供する最大時間を設定することを検討してください。コンテンツの変更頻度が低い Web サイトでは、パフォーマンスを改善するためにこの値を増やすことをお勧めします。

管理コンソールで最大継続時間を設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大継続時間」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-age プロパティーを変更します。デフォルトは 30 秒です。値の範囲は 0.001 〜 3600 です。

最大ヒープキャッシュサイズ

最適なキャッシュヒープサイズは、システムメモリーの空き容量がどのくらい存在するかによって異なります。ヒープサイズを大きくすれば、Web Server がより多くのコンテンツをキャッシュに書き込めるため、ヒット率も向上することになります。ただし、オペレーティングシステムがキャッシュに書き込まれたファイルのページングを開始するほどヒープサイズを大きくすべきではありません。

チューニング

管理コンソールで最大ヒープサイズを設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大ヒープスペースサイズ」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-heap-space プロパティーを変更します。デフォルト値は 10485760 バイトです。値の範囲は 0 〜 9223372036854775807 です。32 ビット Web Server では、プロセスはファイルキャッシュ用に 4G バイトのアドレス空間を使用するため、この値は 4G バイト未満にするべきです。

nocache パラメータの使用

Service 関数send-file でパラメータ nocache を使えば、ある特定のディレクトリ内のファイルをキャッシュに書き込まないように指定できます。この変更を行うには obj.conf を編集します。たとえば、変更頻度が高すぎるためにキャッシュに書き込んでもあまり役に立たないような一連のファイルが存在する場合、それらのファイルをあるディレクトリに格納し、obj.conf を編集してそのディレクトリ内のファイルをキャッシュに書き込まないようにサーバーに指示することができます。

例

<Object name=default>
...
NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir"
name="myname"
...
Service method=(GET|HEAD|POST) type=*~magnus-internal/*
fn=send-file
...
</Object>
<Object name="myname">
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
nocache=""
</Object>

この例では、URL プレフィックス /myurl によって /export/mydir/ 内の静的ファイルが要求された際に、サーバーはそれらのファイルをキャッシュに書き込みません。obj.conf の編集方法の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference 』を参照してください。

ファイルキャッシュの動的な制御と監視

obj.conf にオブジェクトを追加すれば、サーバーの実行中にファイルキャッシュを動的に監視および制御できます。

Procedureファイルキャッシュを制御および監視する

  1. NameTrans 指令をデフォルトオブジェクトに追加します。

    NameTrans fn="assign-name" from="/nsfc" name="nsfc"

  2. nsfc オブジェクトの定義を追加します。

    <Object name="nsfc">
Service fn="service-nsfc-dump"
</Object>

    これにより、ファイルキャッシュを制御および監視するための関数 (nsfc-dump) に、URI /nfsc 経由でアクセスできるようになります。別の URI を使用するには、NameTrans 指令の from パラメータを変更します。

    次に、この URI へのアクセス時に表示される情報の例を示します。


    Sun Java System File Cache Status (pid 3602)

The file cache is enabled.
Cache resource utilization

Number of cached file entries = 174968 (152 bytes each, 26595136 total bytes)
Heap space used for cache = 1882632616/1882632760 bytes
Mapped memory used for medium file contents = 0/1 bytes
Number of cache lookup hits = 47615653/48089040 ( 99.02 %)
Number of hits/misses on cached file info = 23720344/324195
Number of hits/misses on cached file content = 16247503/174985
Number of outdated cache entries deleted = 0
Number of cache entry replacements = 0
Total number of cache entries deleted = 0

Parameter settings

ReplaceFiles: false
ReplaceInterval: 1 milliseconds
HitOrder: false
CacheFileContent: true
TransmitFile: false
MaxAge: 3600 seconds
MaxFiles: 600000 files
SmallFileSizeLimit: 500000 bytes
MediumFileSizeLimit: 1000001 bytes
BufferSize: 8192 bytes

CopyFiles: false
Directory for temporary files: /tmp
Hash table size: 1200007 buckets

    この URI へのアクセス時には、クエリー文字列を含めることができます。次の値が認識されます。

    • ?list: キャッシュ内のファイルを一覧表示する。

    • ?refresh=n: n 秒ごとにクライアントがページの再読み込みを行うようにする。

    • ?restart: キャッシュが停止後、再起動されるようにする。

    • ?start: キャッシュを起動する。

    • ?stop: キャッシュをシャットダウンする。

    ?list オプションを選択する場合、そのファイルリストには、ファイル名、一連のフラグ、現在のキャッシュエントリ参照数、ファイルのサイズ、および内部ファイル ID 値が含まれます。フラグは次のとおりです。

    • C: ファイルのコンテンツがキャッシュに書き込まれている。

    • D: キャッシュエントリが削除対象としてマークされている。

    • E: PR_GetFileInfo() がこのファイルでエラーを返した。

    • I: ファイルの情報 (サイズや変更日付など) がキャッシュに書き込まれている。

    • M: ファイルのコンテンツが仮想メモリー内にマップされている。

    • O: ファイル記述子がキャッシュに書き込まれている (TransmitFile が true に設定されている場合)。

    • P: ファイルに非公開データが関連付けられている (shtml ファイルの場合に表示されるはず)。

    • T: キャッシュエントリが一時ファイルを持っている。

    • W: キャッシュエントリが書き込みアクセス用としてロックされている。

スレッドプール情報

ユーザーがデフォルト設定を使用している場合、デフォルトスレッドプール内のスレッドが要求を処理します。ただし、カスタムスレッドプールを作成し、それらを使ってカスタム NSAPI 関数を実行することもできます。Web Server はデフォルトで、NativePool という名前の追加プールを 1 つ作成します。ほとんどの場合、ネイティブスレッドプールが必要になるのは、Windows プラットフォームの場合だけです。スレッドプールの詳細については、「スレッド、プロセス、および接続の理解」を参照してください。

ネイティブスレッドプール

次の例は、perfdump で表示されるネイティブスレッドプール情報を示したものです。

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0
my-custom-pool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

ユーザーが追加のカスタムスレッドプールを定義した場合、それらのプールは perfdumpの「Native Pools」見出しの下に表示されます。

次の表に、管理コンソールで表示されるスレッドプール統計を示します。ユーザーが追加のスレッドプールを定義しなかった場合は、NativePool のみが表示されます。

表 2–5 スレッドプールの統計

名前 

NativePool 

アイドル状態のスレッド 

1 

スレッド数 

1 

待機した要求 

0 

待機した最大要求数 

0 

アイドル/ピーク/制限

Idle は管理コンソールでは「アイドル状態のスレッド」として表示されますが、これは、現在アイドル状態になっているスレッドの数を示します。Peak は、プール内のピークスレッド数を示します。Limit は管理コンソールでは「スレッド数」として表示されますが、これは、スレッドプール内で許可されるネイティブスレッドの最大数を示しており、NativePool の場合は、magnus.conf ファイル内の NativePoolMaxThreads の設定によって決まります。

チューニング

NativePool の最大スレッド数を変更するには、magnus.conf 内の NativePoolMaxThreads パラメータを編集します。詳細については、「NativePoolMaxThreads 指令」を参照してください。

ワークキューの長さ/ピーク/制限

これらの数値は、プール内のネイティブスレッドを使用するために待機しているサーバー要求のキューに関するものです。Work Queue Length はネイティブスレッドを待機している要求の現在の数であり、管理コンソールでは「待機した要求」として表示されます。

Peak (管理コンソールでは「待機した最大要求数」) は、ネイティブスレッドを使用するためにキュー内に同時に存在していた要求の、サーバーが起動されてからその時点までの最大数です。この値は、ネイティブスレッドを必要とする要求の最大並行性とみなすことができます。

Limit はネイティブスレッドを待機するためにキュー内に一度に格納できる要求の最大数であり、NativePoolQueueSize の設定によって決まります。

チューニング

NativePool のキューサイズを変更するには、magnus.conf 内の NativePoolQueueSize 指令を編集します。詳細については、「NativePoolQueueSize 指令」を参照してください。

NativePoolStackSize 指令

NativePoolStackSize は、ネイティブ (カーネル) スレッドプール内の各スレッドのスタックサイズをバイト単位で決定します。

チューニング

NativePoolStackSize を変更するには、magnus.conf 内の NativePoolStackSize 指令を編集します。

NativePoolQueueSize 指令

NativePoolQueueSize は、スレッドプール用のキュー内で待機できるスレッドの数を決定します。プール内のすべてのスレッドがビジー状態になると、ネイティブプール内のスレッドを使用する必要のある次の要求処理スレッドは、キュー内で待機する必要があります。キューがいっぱいになると、次の要求処理スレッドがキューに入ろうとしても拒否され、最終的にそのスレッドはクライアントにビジー応答を返します。その後、そのスレッドは、キュー内で待機しながら拘束される代わりに、別の受信要求を自由に処理できるようになります。

NativePoolQueueSize を最大スレッド数の値よりも小さい値に設定すると、プールスレッドによるサービスを待機している要求の数がこの値を超えるたびに、サーバーは目的とする NSAPI 関数の代わりにビジー関数を実行します。デフォルトでは、「503 Service Unavailable」応答が返され、ログレベルの設定に応じたメッセージがログに記録されます。NativePoolQueueSize を最大スレッド数よりも大きい値に設定すると、ビジー関数が実行可能になる前にサーバーが接続を拒否します。

この値は、ネイティブスレッドを必要とするサービスを同時に求める要求の最大数を表します。負荷が高いためにシステムが要求を処理できない場合に、待機可能な要求の数を増やすと、要求の待ち時間が長くなり、利用可能なすべての要求スレッドが 1 つのネイティブスレッドを待機することになる可能性があります。一般に、この値は、ネイティブスレッドを必要とする要求を実行する同時ユーザーの最大数を予想し、その要求が拒否されるのを回避できるだけの大きな値に設定します。

この値と最大スレッド数の違いは、静的 HTML や画像ファイルなどの、非ネイティブスレッド要求のために予約される要求数にあります。予約を確保して要求を拒否することで、サーバーが静的ファイルの要求を処理し続けることを保証でき、動的コンテンツの高負荷時にサーバーが応答不能になるのを防ぐことができます。サーバーが常に接続を拒否する場合には、この値の設定が小さすぎるか、あるいはサーバーのハードウェアが過負荷状態になっています。

チューニング

NativePoolQueueSize を変更するには、magnus.conf 内の NativePoolQueueSize 指令を編集します。

NativePoolMaxThreads 指令

NativePoolMaxThreads は、ネイティブ (カーネル) スレッドプール内のスレッドの最大数を決定します。

値を大きくするほど、同時に実行可能な要求が多くなりますが、コンテキストの切り替えによるオーバーヘッドも大きくなります。したがって、値が大きいほど良いとは限りません。通常の場合、この数値を増やす必要はありませんが、CPU がまだ飽和状態に達しておらず、かつ待機中の要求が多数存在している場合には、この数値を増やすべきです。

チューニング

NativePoolMaxThreads を変更するには、magnus.conf 内の NativePoolMaxThreads パラメータを編集します。

NativePoolMinThreads 指令

ネイティブ (カーネル) スレッドプール内のスレッドの最小数を決定します。

チューニング

NativePoolMinThreads を変更するには、magnus.conf 内の NativePoolMinThreads パラメータを編集します。

DNS キャッシュ情報

DNS キャッシュでは、IP アドレスと DNS 名がキャッシュされます。Web Server は、DNS キャッシュを使ってロギングや IP アドレスによるアクセス制御を行います。DNS キャッシュはデフォルトで有効になっています。次の例は、perfdump で表示される DNS キャッシュ情報を示したものです。

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        4/1024
HitRatio            62854802/62862912 ( 99.99%)

AsyncDNS Data:
------------------
enabled             yes
NameLookups         0
AddrLookups         0
LookupsInProgress   0

次の例に、管理コンソールで表示される DNS キャッシュ情報を示します。

表 2–6 DNS キャッシュの統計

キャッシュヒットの合計 

62854802 

キャッシュミスの合計 

6110 

非同期検索の数 

0 

検索中 

4 

非同期検索が有効 

1 

実行した非同期アドレス検索の数 

0 

有効

DNS キャッシュが無効になっていると、このセクションの残りの部分が perfdump で表示されません。管理コンソールではページにゼロが表示されます。

チューニング

DNS キャッシュはデフォルトで有効になっています。管理コンソールで DNS キャッシュを有効または無効にするには、構成の「パフォーマンス」タブ ⇒「DNS」サブタブの、「DNS キャッシュ設定」の下で、「DNS キャッシュ」の「有効」ボックスを選択または選択解除します。コマンド行インタフェースでこれを有効または無効にするには、wadm set-dns-cache-prop を使って enabled プロパティーを設定します。

キャッシュエントリ数 (現在のキャッシュエントリ数/最大キャッシュエントリ数)

perfdump のこのセクションには、キャッシュエントリの現在の数と最大数が表示されます。管理コンソールでは、現在のキャッシュエントリ数は「キャッシュヒットの合計」として表示されます。単一のキャッシュエントリは、単一の IP アドレスまたは単一の DNS 名の検索を表します。キャッシュのサイズは、Web サイトに同時にアクセスするクライアントの最大数と同程度にするべきです。キャッシュサイズが大きすぎるとメモリーが浪費され、パフォーマンスも低下します。

チューニング

管理コンソールで DNS キャッシュの最大サイズを設定するには、構成の「パフォーマンス」タブ ⇒「DNS」サブタブの、「DNS キャッシュ設定」の下にある「最大キャッシュサイズ」フィールドを使用します。コマンド行インタフェースでこれを設定するには、wadm set-dns-cache-prop を使って max-entries プロパティーを設定します。デフォルトのキャッシュサイズは 1024 です。値の範囲は 2 〜 32768 です。

ヒット率 (キャッシュヒット数/キャッシュ検索数)

perfdump のヒット率には、キャッシュ検索数に対するキャッシュヒット数が表示されます。管理コンソールの統計に基づいてこの数値を計算するには、「キャッシュヒットの合計」と「キャッシュミスの合計」を足したもので、「キャッシュヒットの合計」を割ります。

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

非同期 DNS が有効/無効

Async DNS enabled/disabled には、サーバーがオペレーティングシステムの同期リゾルバの代わりに独自の非同期 DNS リゾルバを使用するかどうかが表示されます。非同期 DNS はデフォルトで無効になっています。これが無効になっていると、このセクションが perfdump で表示されません。管理コンソールでこれを有効にするには、構成の「パフォーマンス」タブ ⇒「DNS」タブの「DNS 検索設定」の下で、「非同期 DNS」を選択します。コマンド行インタフェースでこれを有効にするには、wadm set-dns-prop を使って async プロパティーを true に設定します。

Java 仮想マシン (JVM) 情報

JVM の統計が表示されるのは、管理コンソール、CLI、および stats-xml を使用する場合だけです。perfdump ではそれらは表示されません。

次の表に、管理コンソールで表示される JVM 統計の例を示します。

表 2–7 Java 仮想マシン (JVM) の統計

仮想マシン名 

Java HotSpotTM Server VM

仮想マシンベンダー 

Sun Microsystems Inc. 

仮想マシンのバージョン 

1.5.0_06-b05 

ヒープメモリーサイズ 

5884856 

ガベージコレクション経過時間 (ミリ秒) 

51 

読み込んだクラスの現在の数 

1795 

読み込んだクラスの合計数 

1795 

読み込み解除したクラスの合計数 

0 

発生したガベージコレクションの数 

3 

ライブスレッドの数 

8 

開始したスレッドの数 

9 

最大ライブスレッドカウント 

8 

これらの統計のほとんどは、チューニング不可能です。これらは、JVM の動作に関する情報を提供します。

JVM に関するチューニング情報のもう 1 つの情報源は、JVM を監視および管理するための管理インタフェースを提供するパッケージ java.lang.management です。このパッケージの詳細については、http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/package-summary.html を参照してください。

Java ヒープチューニング

Web Server での Web アプリケーションのパフォーマンスは、ほかのすべての Java プログラムの場合と同じく、JVM が実行するヒープ管理に依存します。一時停止の時間とスループットの間には、トレードオフの関係が成立します。手始めに、http://java.sun.com/docs/hotspot/index.html から入手可能な Java HotSpot 仮想マシンのパフォーマンスドキュメントを読んでみてください。

具体的な関連ドキュメントとしては、『Tuning Garbage Collection with the 5.0 Java Virtual Machine』 や『Ergonomics in the 5.0 Java Virtual Machine』 などが挙げられます。

JVM オプションを管理コンソールで指定するには、構成の「Java」タブ ⇒「JVM 設定」サブタブを使用します。CLI では、wadm コマンド set-jvm-prop および set-jvm-profiler-prop を使用します。

Web アプリケーション情報

Web アプリケーション統計が表示されるのは、管理コンソール、wadm get-config-stats コマンド、および stats-xml を使用する場合だけです。perfdump ではそれらは表示されません。

Procedure管理コンソールから Web アプリケーション統計にアクセスする

  1. 「共通操作」ページから「監視」タブを選択します。

  2. 構成の Web アプリケーション統計を表示するには、構成名をクリックします。インスタンスの Web アプリケーション統計を表示するには、「インスタンス」サブタブをクリックし、インスタンス名をクリックします。

  3. 「監視統計」ページで、「仮想サーバーの統計」をクリックします。

  4. 仮想サーバー名をクリックします。

  5. 「仮想サーバーの監視統計」ページで「Web アプリケーション」をクリックします。

  6. 統計を表示する Web アプリケーションを、「Web アプリケーション」プルダウンメニューから選択します。

Web アプリケーションの統計

次の表に、管理コンソールで表示される Web アプリケーション統計の例を示します。

表 2–8 Web アプリケーションの統計

読み込んだ JSP の数 

1 

再読み込みした JSP の数 

1 

提供されたセッションの合計数 

2 

アクティブなセッションの数 

2 

アクティブセッションの最大数 

2 

拒否されたセッションの数 

0 

期限切れセッションの数 

0 

期限切れセッションが有効であった平均時間 (秒) 

0 

期限切れセッションが有効であった最長時間 (秒) 

0 

チューニング方法の詳細については、「Java Web アプリケーションのパフォーマンスチューニング」を参照してください。また、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』も参照してください。

JDBC リソース情報

JDBC リソースとは、データベースへの JDBC 接続の名前付きグループのことです。JDBC リソースは、接続プールの作成に使用されるプロパティーを定義します。各 JDBC リソースは、サーバー起動時に JDBC ドライバを使って物理データベースへの接続を確立します。接続のプールが作成されるのは、Web Server の起動後、そのプールに対して最初の接続要求が発行されたときです。

JDBC ベースのアプリケーションまたはリソースは、プールから接続を取り出し、その接続を使用し、その接続が不要になった時点でそれをクローズして接続プールに返します。2 つ以上の JDBC リソースが同じプール定義を指している場合、それらのリソースは実行時に同じ接続プールを使用します。

接続プールを使用すると、次の処理によってアプリケーションのパフォーマンスが改善されます。

JDBC リソースの作成および編集は、管理コンソールの、構成に対する「Java」タブ ⇒「リソース」サブタブを使って行えます。また、 wadm create-jdbc-resource および set-jdbc-resource-prop コマンドを使用することもできます。詳細については、『Sun Java System Web Server 7.0 管理ガイド』を参照してください。

注 –

Web Server の起動時に各定義済みプールがインスタンス化されます。ただし、プールへのアクセスがはじめて発生するまで、接続が作成されることはありません。プールに重い負荷をかける前に、プールを軽く使用しておくべきです。

JDBC リソースの統計が利用可能になるのは、管理コンソール、CLI、および stats.xml を使用する場合だけです。perfdump ではそれらは表示されません。一部の監視データは、管理コンソール経由では利用できず、CLI の wadm get-config-stats および stats.xml 出力経由でしか表示できません。

プールはオンデマンドで作成されます。つまり、プールははじめて使用される時点で作成されます。監視統計は、プールがはじめて使用されるまで表示されません。

管理コンソール経由で利用可能な JDBC リソース統計

次の表に、管理コンソール経由で表示される JDBC リソース統計の例を示します。

表 2–9 JDBC リソース統計

接続 

32 

未使用接続 

0 

リース接続 

32 

平均キュー時間 

1480.00 

待機接続 

40 

接続タイムアウト 

100 

管理コンソール経由で JDBC リソースの設定を変更するには、対応する構成で、「Java」タブ ⇒「リソース」サブタブを選択します。JDBC リソースを選択します。「JDBC リソースを編集」ページで設定が利用可能になります。コマンド行インタフェース経由で JDBC リソースを変更するには、wadm set-jdbc-resource-prop を使用します。

接続数

この数値は現在の JDBC 接続数を示しており、未使用接続数とビジー接続数の両方を含みます。

チューニング – この設定はチューニング不可能ですが、プールの最新のアクティビティーを知るための良い指標になります。接続数が最小接続数よりも常に大きい場合、その現在の JDBC 接続数に近い値になるように最小接続数を増やすことを検討してください。管理コンソール経由で JDBC リソースの最小接続数を変更するには、「JDBC リソースを編集」ページで「最小接続数」設定を編集します。コマンド行インタフェース経由で JDBC リソースの最小接続数を変更するには、wadm set-jdbc-resource-prop を使って min-connections プロパティーを変更します。

未使用接続数

この数値は、プール内の未使用接続の現在数を示します。最小プールサイズを超える未使用接続はすべて、アイドル状態が最大アイドルタイムアウトを超えると閉じられます。未使用接続数はチューニング不可能です。

リース接続数

この数値は、プール内の使用中接続の現在数を示します。

チューニング – リース接続数が最小接続数よりも常に小さい場合、JDBC リソースの最小接続数を減らすことを検討してください。リース接続数が最小接続数よりも常に大きい場合、最小接続数を増やすことを検討してください。リース接続数が JDBC リソースの最大接続数と常に等しくなる場合、最大接続数を増やすことを検討してください。リース接続数の上限は最大接続数になります。

管理コンソール経由で JDBC リソースの最小接続数または最大接続数を変更するには、「JDBC リソースを編集」ページで「最小接続数」または「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最小接続数または最大接続数を変更するには、wadm set-jdbc-resource-prop を使って min-connections または max-connections プロパティーを変更します。

待機接続数

この数値は、JDBC プールから接続を受け取るために待機している接続要求の現在数を示します。現在のリース接続数が最大接続数に達すると、接続要求がキューに入れられます。

チューニング – この数値がゼロより常に大きい場合、JDBC リソースの最大接続数を増やすことを検討してください。管理コンソール経由で JDBC リソースの最大接続数を変更するには、「JDBC リソースを編集」ページで「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最大接続数を変更するには、wadm set-jdbc-resource-prop を使って max-connections プロパティーを変更します。

管理コンソールで利用不可能な JDBC リソース統計

一部の JDBC 統計は、wadm get-config-stats コマンド (--node オプションを使用)、stats-xml、および SNMP 経由では利用可能ですが、管理コンソール経由では利用不可能です。

maxConnections – 構成されたプールの最大サイズ。ほかの統計の基準値として使用してください。管理コンソール経由で JDBC リソースの最大接続数を変更するには、「JDBC リソースを編集」ページで「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最大接続数を変更するには、wadm set-jdbc-resource-prop を使って max-connections プロパティーを変更します。

peakConnections – プールの履歴に含まれている、同時にリースされた接続の数のうちで、最大のもの。この数値は、プール使用時の上限を知るための良い指標になります。これは、最大接続数の設定によって制限されます。

countTotalLeasedConnections – プールによって接続が提供された回数の合計。プールの総合的なアクティビティーを示します。チューニング不可能です。

countTotalFailedValidationConnections – 接続の検証が有効になっている場合、プールによって接続が無効であると判定された回数を示します。この数値が比較的大きい場合、それは、データベースやネットワークで問題が発生していることを意味している可能性があります。チューニング不可能です。

peakQueued – プールの寿命内の任意の時点で同時にキューに入っていた接続要求の数のうちで、最大のもの。チューニング不可能です。

millisecondsPeakWait – 任意の接続要求が待機キュー内に存在していたミリ秒単位の時間のうちで、最長のもの。この数値が大きい場合、それは、プールのアクティビティーが活発であることを示しています。上限は、JDBC リソース設定の待機タイムアウトになります。

countConnectionIdleTimeouts – 構成された JDBC アイドルタイムアウトを超過したためにプールによって閉じられた未使用接続の数。管理コンソール経由で JDBC リソースのアイドルタイムアウトを変更するには、「JDBC リソースを編集」ページで「アイドルタイムアウト」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースのアイドルタイムアウトを変更するには、wadm set-jdbc-resource-prop を使って idle-timeout プロパティーを変更します。

JDBC リソースの接続設定

アプリケーションのデータベースアクティビティーによっては、JDBC リソースの接続プール設定のサイズを変更しなければいけない可能性があります。パフォーマンスに影響を与える JDBC リソースの属性のリストと、その値を設定する際のパフォーマンス上の考慮点を、次に示します。

ACL ユーザーキャッシュのチューニング

ACL ユーザーキャッシュはデフォルトで有効になっています。ACL ユーザーキャッシュは、そのデフォルトサイズ (200 件のエントリ) のために、障害の 1 つになるか、あるいは単純に高トラフィックのサイト上でその目的を果たせない可能性があります。ビジー状態のサイトでは、200 件を超えるユーザーが、ACL で保護されたリソースをキャッシュエントリの寿命内でヒットする可能性があります。そうした状況が発生すると、Web Server はユーザーを検証するために LDAP サーバーに対するクエリーをより頻繁に行う必要が生じますが、そのことがパフォーマンスに悪影響を及ぼします。

この障害を解消するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」サブタブで、ACL キャッシュの最大ユーザー数を増やします。また、コマンド wadm set-acl-cache-prop を使って max-users プロパティーを設定することによっても、ユーザー数を設定することができます。キャッシュサイズを増やすとリソースの使用量も増えることに注意してください。キャッシュを大きくするほど、それを保持するために必要となる RAM も多くなります。

また、1 つのキャッシュエントリ内に格納されるグループの数 (デフォルトでは 4) が障害になる可能性もあります (ただし、その可能性は格段に低い)。5 つのグループに所属するユーザーが、ACL キャッシュの寿命内でそれらの異なるグループをチェックするための 5 つの ACL をヒットした場合、追加のキャッシュエントリが 1 つ作成され、そこに追加のグループエントリが格納されます。キャッシュエントリが 2 つ存在している場合、元のグループの情報を含むエントリは無視されます。

このパフォーマンス問題が発生することはきわめてまれですが、構成の「パフォーマンス」タブ ⇒「キャッシュ」サブタブの「最大グループ数」設定を使用すれば、単一の ACL キャッシュエントリ内にキャッシュされるグループの数のチューニングを行えます。あるいは、wadm set-acl-cache-prop コマンドの max-groups-per-user プロパティーを使用することもできます。

ACL キャッシュの最大継続時間の設定により、キャッシュエントリが期限切れになるまでの秒数が決まります。キャッシュのエントリが参照されるたびにその経過時間が計算され、最大継続時間の設定と照合されます。エントリの継続時間が最大継続時間よりも大きいかそれと等しい場合、そのエントリは使用されません。デフォルト値は 120 秒です。LDAP が頻繁に変更される可能性が低い場合には、大きい数値を最大継続時間として使用してください。これに対し、LDAP のエントリが頻繁に変更される場合には、小さい値を使用してください。たとえば、この値が 120 秒である場合、Web Server と LDAP サーバーの同期が 2 分間にわたって取られない可能性があります。環境によって、それが問題になる可能性も、ならない可能性もあります。

Java Web アプリケーションのパフォーマンスチューニング

この節には、Java Web アプリケーションのパフォーマンス改善に役立つ情報が含まれています。この節では、次の内容について説明します。

さらに次の各節も参照し、Java Web アプリケーションに関するその他のチューニング情報を確認してください。

プリコンパイルされた JSP の使用

JSP のコンパイルは、比較的長い時間のかかる、リソース集約型のプロセスです。Web Server はデフォルトで、JSP が変更されたかどうかを定期的にチェックし、それらを動的に再読み込みします。これにより、サーバーを再起動することなしに変更を配備できます。sun-web.xml 内の jsp-config 要素の reload-interval プロパティーは、サーバーによる JSP の変更有無のチェック頻度を制御します。ただし、このチェックを行うと、パフォーマンスが若干低下します。

サーバーがある .jsp ファイル内で変更を検出すると、その JSP だけの再コンパイルと再読み込みが行われます。Web アプリケーション全体の再読み込みは行われません。

JSP が変更されない場合には、それらの JSP をプリコンパイルすることで、パフォーマンスを改善できます。

管理コンソールまたは CLI のいずれかを使って Web アプリケーションを追加するときに、JSP をプリコンパイルするオプションを選択します。JSP のプリコンパイルを有効にすると、Web アプリケーション内に存在するすべての JSP がプリコンパイルされ、それらの対応するサーブレットクラスが、その Web アプリケーションの WEB-INF/lib または WEB-INF/classes ディレクトリ内にバンドルされます。ある JSP へのアクセスが発生すると、その JSP がコンパイルされるのではなく、代わりにそのプリコンパイルされたサーブレットが使用されます。JSP の詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』を参照してください。また、「クラス再読み込みの設定」も参照してください。

サーブレット/JSP キャッシュの使用

同じサーブレット/JSP の再実行に長時間を費やしている場合には、その結果をキャッシュに書き込んでおき、次回実行時にキャッシュからその結果を取り出して返すことができます。たとえば、これは、サイトを訪れたすべてのユーザーが実行する共通クエリーなどで役立ちます。クエリーの結果は日々変わる可能性があるので動的でなければいけませんが、そのロジックをユーザーごとに実行する必要はありません。

キャッシュを有効にするには、アプリケーションの sun-web.xml ファイル内のキャッシュパラメータを構成します。詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』の「Caching Servlet Results」を参照してください。

Java セキュリティーマネージャーの設定

Web Server は Java セキュリティーマネージャーをサポートします。セキュリティーマネージャーを使って実行することの最大の欠点は、パフォーマンスに悪影響を及ぼす点です。Java セキュリティーマネージャーは、製品のインストール時にデフォルトで無効になります。セキュリティーマネージャーを使わずに実行すれば、アプリケーションの種類によっては、パフォーマンスが大幅に改善される可能性があります。実行時にセキュリティーマネージャーを使用するかどうかは、アプリケーションや配備のニーズに基づいて判断するようにしてください。詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』を参照してください。

クラス再読み込みの設定

サーブレットコンテナの動的再読み込み間隔と、sun-web.xml 内の class-loader 要素の dynamic-reload-interval によって、サーバーがサーブレットクラスの変更有無をチェックする頻度が決まります。動的再読み込みが有効になっていて、かつある .class ファイルの変更をサーバーが検出した場合、その Web アプリケーション全体の再読み込みが行われます。

動的再読み込み間隔を設定するには、構成の「Java」タブ ⇒「サーブレットコンテナ」サブタブを開くか、wadm set-servelt-container-props コマンドを使用します。変更がスケジュールに従って行われるような本稼働環境では、この値を 0 に設定することで、サーバーが常に更新チェックを行うのを防ぎます。デフォルト値は 0 (つまりクラスの再読み込みが無効) です。sun-web.xml 内の要素の詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications 』を参照してください。

クラスパス内でのディレクトリの回避

特定のアプリケーション (特に Java セキュリティーマネージャーが有効になっている場合) では、クラスパス内に不要なディレクトリが存在しないようにすることで、パフォーマンスを改善できます。そうするには、構成の「Java」タブ ⇒「一般」サブタブにある「サーバークラスパス」、「クラスパスのプレフィックス」、および「クラスパスのサフィックス」フィールドを変更するか、コマンド wadm set-jvm-prop を使用します。さらに、Web アプリケーションの .class ファイルをそのまま WEB-INF/classes 内にパッケージ化する代わりに、それらの .class ファイルを .jar アーカイブとして WEB-INF/lib 内にパッケージ化し、WEB-INF/classes ディレクトリが .war アーカイブに含まれていないことを確認します。

Web アプリケーションのセッション設定の構成

セッションの寿命が比較的短い場合、sun-web.xml 内の session-properties 要素の下にある timeOutSeconds プロパティーの値をデフォルト値の 10 分から減らすことで、セッションタイムアウトを減らしてみてください。

セッションの寿命が比較的長い場合、reapIntervalSeconds プロパティーの値をデフォルト値の毎分 1 回から増やすことで、セッションリーパーの実行頻度を減らしてみることができます。

これらの設定やセッションマネージャーの詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』を参照してください。

マルチプロセスモードで、sun-web.xml の persistence-type が s1ws60 または mmap のいずれかに構成されている場合、セッションマネージャーはクロスプロセスロックを使ってセッションデータの整合性を維持します。これらを次の説明に従って設定すれば、パフォーマンスを改善できます。

注 –

マルチプロセスモードは非推奨であり、下位互換性を維持するためだけに含まれています。

maxLocks のチューニング (UNIX/Linux)

maxLocks プロパティーに指定された数の意味は、maxSessions の値を maxLocks で割ってみれば理解できます。たとえば、maxSessions = 1000 の場合に maxLocks = 10 と設定すると、約 100 個のセッション (1000/10) が同じロック上で競合することになります。maxLocks を増やすと、同じロック上で競合するセッションの数が減るので、パフォーマンスが改善し、待ち時間が短縮される可能性があります。ただし、ロックの数を増やすとオープン状態のファイル記述子の数も増えます。そのため、ロックの数を増やさなければ受信接続要求に割り当てられるはずだった利用可能な記述子の数が、減ることになります。

これらの設定の詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』の第 6 章「Session Managers」を参照してください。

MMapSessionManager のチューニング (UNIX/Linux)

次の例では、manager-properties プロパティーを使って persistence-type="mmap" と構成する場合に、プロセスサイズにどのような影響があるかについて説明します。詳細については、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』の「MMap Session Manager (UNIX Only)」を参照してください。

maxSessions = 1000
maxValuesPerSession = 10
maxValueSize = 4096

この例の場合、サイズ 1000 X 10 X 4096 バイト、つまり約 40M バイトのメモリーマップファイルが作成されます。これはメモリーマップファイルなので、起動時のプロセスサイズが 40M バイトだけ増えます。これらのパラメータに設定する値が大きいほど、プロセスサイズの増加量も増えます。

CGI スタブプロセスのチューニング (UNIX/Linux)

Web Server では、CGI エンジンが必要に応じて CGI スタブプロセスを作成します。CGI によって生成されるコンテンツに大きく依存する高負荷システムでは、CGI スタブプロセスがすべてのシステムリソースを消費してしまう可能性があります。サーバーでそうした状況が発生している場合、CGI スタブプロセスのチューニングを行うことで、作成可能な新しい CGI スタブプロセスの数、そのタイムアウト値、および任意の時点で実行される CGI スタブプロセスの最小数を制限することができます。

注 –

magnus.conf ファイル内に init-cgi 関数が存在していて、かつサーバーがマルチプロセスモードで稼働している場合、その init-cgi 行に LateInit = yes を追加する必要があります。

マルチプロセスモードは非推奨であり、将来のリリースでは存在しない可能性があります。

CGI スタブを制御するには、次の設定をチューニングしてください。これらの設定は、構成の「パフォーマンス」タブ ⇒「CGI」サブタブにあります。

find-pathinfo-forward の使用

obj.conf 内で find-pathinfo-forward パラメータを使用すると、パフォーマンスの改善を図りやすくなります。これは、PathCheck 関数 find-pathinfo、および NameTrans 関数 pfx2dir および assign-name で使用されます。find-pathinfo-forward パラメータは、PATH_INFO の検索を、サーバー関数 find-pathinfo 内のパスの末尾から逆方向に行う代わりに、ntrans-base のあとのパス内で順方向に行うように、サーバーに指示します。

注 –

サーバー関数 find-pathinfo の呼び出し時に ntrans-base パラメータが rq->vars 内に設定されていないと、サーバーは find-pathinfo-forward パラメータを無視します。ntrans-base はデフォルトで設定されています。

例 

NameTrans fn="pfx2dir" find-pathinfo-forward="" from="/cgi-bin" 
dir="/export/home/cgi-bin" name="cgi"
NameTrans fn="assign-name" from="/perf" 
find-pathinfo-forward="" name="perf"

この機能を使えば、サーバー関数 find-pathinfo での stat の実行回数が少なくなるため、特定 URL でのパフォーマンスの改善を図れます。また、Windows の場合、PathCheck サーバー関数 find-pathinfo の使用時にサーバーが「\\」を「/」に変更するのを回避するためにこの機能を使用することもできます。

obj.conf の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』を参照してください。

nostat の使用

obj.conf の NameTrans 関数 assign-name でパラメータ nostat を指定すれば、指定された URL 上でサーバーが stat を実行するのを可能なかぎり回避できます。構文は次のとおりです。

nostat=virtual-path

例 

<Object name=default>
NameTrans fn="assign-name" from="/nsfc" nostat="/nsfc" name="nsfc"
</Object>
<Object name=nsfc>
Service fn=service-nsfc-dump
</Object>

この例では、ntrans-base が設定されている場合、パス / ntrans-base/nsfc および / ntrans-base/nsfc/* でサーバーは stat を実行しません。ntrans-base が設定されていない場合、URL /nsfc および /nsfc/* でサーバーは stat を実行しません。ntrans-base はデフォルトで設定されています。この例では、デフォルトの PathCheck サーバー関数が使用されるものと仮定しています。

assign-name NameTrans で nostat=virtual-path を使用すると、指定された virtual-path 上で stat を実行しても失敗すると、サーバーは仮定します。したがって、nostat を使用するのは、NSAPI プラグインの URL のように、virtual-path のパスがシステム上に存在しない場合だけにしてください。そうした URL で nostat を使用すると、そうした URL での不要な stat 実行が避けられるため、パフォーマンスが改善されます。

obj.conf の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』を参照してください。

ビジー関数の使用

デフォルトのビジー関数は「503 Service Unavailable」応答を返し、ログレベルの設定に応じたメッセージをログに記録します。アプリケーション向けにこの動作を変更することをお勧めします。obj.conf ファイル内の任意の NSAPI 関数でユーザー独自のビジー関数を指定するには、その構成ファイル内でサービス関数を次の形式で含めます。

busy="my-busy-function"

たとえば、次のサンプルサービス関数を使用できます。

Service fn="send-cgi" busy="service-toobusy"

これにより、いくつかのタイプ (Service、AddLog、PathCheck など) を含む要求処理の途中でサーバーが深刻なビジー状態に陥った場合に、さまざまな応答を返すことが可能となります。デフォルトのスレッドタイプが非ネイティブである場合、実行にネイティブスレッドを必要とするすべての関数にビジー関数が適用されます。

サーバー全体で、デフォルトのビジー関数の代わりにユーザー独自のビジー関数を使用するには、次のような、func_insert 呼び出しを含む NSAPI init 関数を記述します。

extern "C" NSAPI_PUBLIC int my_custom_busy_function
(pblock *pb, Session *sn, Request *rq);
my_init(pblock *pb, Session *, Request *){func_insert
("service-toobusy", my_custom_busy_function);}

プールスレッド上では、ビジー関数が実行されることは決してないため、スレッドのブロックを引き起こす可能性のある関数呼び出しを使用しないように注意する必要があります。