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

サーバーパフォーマンスの監視

このマニュアルで説明されている調整を、それらの効果を測定せずに行なっても意味はありません。変更を行う前とあとにシステムの動作を測定しなければ、その変更が良い考えだったか、悪い考えだったか、あるいは無関係だったかがわかりません。Web Server のパフォーマンスは、次に示す何種類かの方法で監視できます。

表 1–1 パフォーマンスの監視方法


監視方法	有効にする方法	アクセス方法	利点と要件
管理コンソール経由の統計情報	デフォルトで有効	管理コンソールで、構成の「監視」タブをクリックします	セッションスレッドがハングアップしている場合にアクセス可能。管理サーバーが実行されている必要があります。
個別の `wadm` コマンド経由の統計情報	デフォルトで有効	次の `wadm` コマンドを経由します `get-config-statsget-virtual-server-stats` `get-webapp-stats` `get-servlet-stats`	セッションスレッドがハングアップしている場合にアクセス可能。管理サーバーが実行されている必要があります。
ブラウザ経由の XML 形式の統計情報 (`stats-xml`)	管理コンソール、または設定ファイルの編集を経由して有効にします	URI を経由します	管理サーバーが実行されている必要はありません。
コマンド行インタフェース経由の XML 形式の統計情報 (`stats-xml`)	デフォルトで有効	`wadm` コマンド `get-stats-xml` を経由します	セッションスレッドがハングアップしている場合にアクセス可能。管理サーバーが実行されている必要があります。
ブラウザ経由の `perfdump`	管理コンソール、または設定ファイルの編集を経由して有効にします	URI を経由します	管理サーバーが実行されている必要はありません。
コマンド行インタフェース経由の `perfdump`	デフォルトで有効	`wadm` コマンド `get-perfdump` を経由します	セッションスレッドがハングアップしている場合にアクセス可能。管理サーバーが実行されている必要があります。
Java ES の監視	デフォルトで有効	Java ES 監視コンソールを経由します	Java ES インストールでのみ使用可能。管理サーバーが実行されている必要があります。

サーバーの監視は、コンピューティングリソースにある程度の影響を与えます。一般に、影響がもっとも少ないのは URI を経由した perfdump の使用であり、次が URI を経由した stats-xml の使用です。管理サーバーの使用はコンピューティングリソースを消費するため、コマンド行インタフェースと管理コンソールがもっとも影響の大きい監視方法です。

これらの監視方法の詳細については、以降の節を参照してください。

統計情報について

管理コンソールのユーザーインタフェース、コマンド行インタフェース、stats-xml URI、および perfdump を経由して、多くのパフォーマンス統計情報を監視できます。これらの監視方法のすべてについて、サーバーは収集した統計情報を使用します。統計情報が収集されないかぎり、これらのどの監視方法も機能しません。

これらの統計情報によって、構成レベル、サーバーインスタンスレベル、または仮想サーバーレベルの情報が得られます。統計情報は、機能別に分類されます。

構成については、次の項目の統計情報を表示できます。

要求
エラー
応答時間

サーバーインスタンスについては、次の項目の統計情報を表示できます。

要求
エラー
応答時間
一般
Java 仮想マシン (JVM^TM)
接続キュー
キープアライブ
DNS
ファイルキャッシュ
スレッドプール
セッションレプリケーション
プロファイルデータを含むセッションスレッド (プロファイリングが有効になっている場合に表示可能)
Java Database Connectivity (JDBC^TM) (JDBC リソースが作成され、接続プールにアクセスしている場合に表示可能)

仮想サーバーについては、次の項目の統計情報を表示できます。

一般
応答
Web アプリケーション
プロファイルデータ (プロファイリングが有効になっている場合に表示可能)
サーブレットとサーブレット応答キャッシュ (sun.web.xml でサーブレットキャッシュが有効になっている場合に表示可能)

サービスの品質 (QoS) が有効になっていない場合は、一部の統計情報、たとえば、開いている接続の数、開いている接続の最大数、転送レート (バイト数)、最大転送レート (バイト数) などはデフォルトで 0 になります。

統計情報の有効化

Web Server では、統計情報はデフォルトでアクティブになります。ただし、いったん無効にした場合、サーバーのパフォーマンスを監視するにはもう一度有効にする必要があります。統計情報を有効にするには、管理コンソールまたは wadm コマンド行ユーティリティー (CLI) を使用します。

注 –

統計情報の収集は、パフォーマンスに若干の影響を与えます。

管理コンソールから統計情報を有効にする

管理コンソールの「共通操作」ページで、構成を選択します。

「構成を編集」をクリックします。

「一般」タブをクリックします。

「監視設定」サブタブをクリックします。

「監視設定」ページの「一般設定」で、「統計コレクション」の「有効」チェックボックスを選択します。

間隔とプロファイリングを設定します。
- この間隔は、統計情報の更新の間の期間 (秒単位) です。この設定を大きくする (頻度を少なくする) ほど、パフォーマンスは向上します。最小値は 0.001 秒、デフォルト値は 5 秒です。
- プロファイリングは、デフォルトでアクティブになります。プロファイリングを非アクティブにすると、監視のオーバーヘッドは若干減ります。

サーバーを再起動します。

CLI から統計情報を有効にする

統計情報の収集を有効にするには、次の CLI コマンドを入力します。

./wadm set-stats-prop --user=admin_user –password-file= password-file --config=myconfig enabled=true

統計情報を無効にするには、enabled を false に設定します。

間隔を設定したり、プロファイリングを有効にしたりするには、set-stats-prop interval および profiling プロパティーを使用します。詳細については、set-stats-prop のヘルプを参照してください。

サーバーを再起動します。

管理コンソールを使用した現在のアクティビティーの監視

頻繁に使用される統計情報は管理コンソールから表示でき、一般統計、インスタンスの統計、および仮想サーバーの統計として表示されます。

管理コンソールから統計情報を監視する

管理コンソールの「共通操作」ページで、「監視」タブを選択します。

構成を選択します。

構成の統計が表示されます。

ドロップダウンリストの「ビュー」から間隔を選択します。

ブラウザに表示される統計情報は、この間隔で自動的に更新されます。

表示する統計情報の種類を選択します。

統計情報の種類の初期リストには、「一般統計」、「インスタンスの統計」、および「仮想サーバーの統計」が含まれています。

「インスタンスの統計」を選択する場合は、監視するインスタンスの名前をクリックします。それにより、プロセスやセッションレプリケーションに関する情報を含む、詳細な統計情報が表示されます。

「仮想サーバーの統計」を選択する場合は、監視する仮想サーバーの名前をクリックします。応答の統計や Web アプリケーションの統計を含む、仮想サーバーの統計情報が表示されます。この情報は、perfdump では表示されません。

CLI を使用した現在のアクティビティーの監視

wadm コマンド get-config-stats、get-virtual-server-stats、get-webapp-stats、および get-servlet-stats を使用して統計情報を表示することもできます。次の例には、可能性のあるすべてのコマンドオプションは含まれていないことに注意してください。完全な構文については、コマンドのヘルプを参照してください。

CLI から統計情報を監視する

1 つのノードに配備されている構成の統計情報を取得するには、次のコマンドを入力します。

./wadm get-config-stats --user=admin-user --password-file=admin-password-file --config= config-name --node=node-name

この構文で node オプションを使用すると、出力が 1 つのノードに制限されます。構成レベルの統計情報を取得するには、このコマンドを node オプションを指定せずに使用します。

1 つのノードの出力の例を次に示します。

timeStarted=1168035653
secondsRunning=1404
countRequests=690546
rpsLast1MinAvg=4491.7666
rpsLast5MinAvg=1844.6061
rpsLast15MinAvg=637.37305
countErrors=0
epsLast1MinAvg=0.0
epsLast5MinAvg=0.0
epsLast15MinAvg=0.0
maxResponseTime=0.30789953
rtLast1MinAvg=5.3970284
rtLast5MinAvg=5.208407
rtLast15MinAvg=35.56042
countBytesReceived=96800935
countBytesTransmitted=689929574
countChildDied=0
countVirtualServers=2
instanceName=https-test
process.1.countThreadPools=2
process.1.jdbcPoolCount=1
process.1.countThreads=64
process.1.fractionSystemMemoryUsage=2887.0
process.1.countConnectionQueues=1
process.1.sizeResident=0
process.1.countIdleThreads=32
process.1.mode=1
process.1.sizeVirtual=0
process.1.countConfigurations=1
process.1.pid=15874
process.1.timeStarted=Jan 5, 2007 2:20:53 PM
process.1.DNSCache.countCacheHits=687804
process.1.DNSCache.countAsyncNameLookup=0
process.1.DNSCache.countAsyncLookupsInProgress=0
process.1.DNSCache.flagAsyncEnabled=false
process.1.DNSCache.countAsyncAddrLookups=0
process.1.DNSCache.flagCacheEnabled=true
process.1.DNSCache.countCacheMisses=75
process.1.JDBCPool.1.countQueued=32
process.1.JDBCPool.1.countFreeConnections=0
process.1.JDBCPool.1.peakConnections=32
process.1.JDBCPool.1.millisecondsPeakWait=72
process.1.JDBCPool.1.countWaitQueueTimeouts=288
process.1.JDBCPool.1.peakQueued=64
process.1.JDBCPool.1.maxConnections=32
process.1.JDBCPool.1.currentConnections=32
process.1.JDBCPool.1.millisecondsAverageQueued=1.0
process.1.JDBCPool.1.countTotalFailedValidationConnections=0
process.1.JDBCPool.1.countLeasedConnections=32
process.1.JDBCPool.1.countTotalLeasedConnections=414
process.1.JDBCPool.1.countConnectionIdleTimeouts=1
process.1.JDBCPool.1.name=jdbc/jdbc-simple_1
process.1.connectionQueue.1.countQueued15MinuteAverage=4.3203125
process.1.connectionQueue.1.countQueued=0
process.1.connectionQueue.1.countQueued1MinuteAverage=0.046875
process.1.connectionQueue.1.countTotalQueued=79171
process.1.connectionQueue.1.countQueued5MinuteAverage=4.03125
process.1.connectionQueue.1.countOverflows=0
process.1.connectionQueue.1.maxQueued=1288
process.1.connectionQueue.1.ticksTotalQueued=724956383
process.1.connectionQueue.1.countTotalConnections=863
process.1.connectionQueue.1.peakQueued=64
process.1.connectionQueue.1.name=cq1
process.1.fileCache.countContentMisses=7
process.1.fileCache.maxMmapCacheSize=0
process.1.fileCache.sizeHeapCache=27520
process.1.fileCache.countMisses=22
process.1.fileCache.countContentHits=620662
process.1.fileCache.maxEntries=1024
process.1.fileCache.flagEnabled=true
process.1.fileCache.secondsMaxAge=30
process.1.fileCache.sizeMmapCache=0
process.1.fileCache.countInfoHits=1862013
process.1.fileCache.maxHeapCacheSize=10747924
process.1.fileCache.countOpenEntries=0
process.1.fileCache.countHits=2482682
process.1.fileCache.maxOpenEntries=1024
process.1.fileCache.countEntries=12
process.1.fileCache.countInfoMisses=19
process.1.jvm.countGarbageCollections=96
process.1.jvm.sizeHeap=67762048
process.1.jvm.countThreads=79
process.1.jvm.countClassesUnloaded=0
process.1.jvm.vMVendor=Sun Microsystems Inc.
process.1.jvm.countTotalClassesLoaded=3170
process.1.jvm.vMName=Java HotSpot(TM) Server VM
process.1.jvm.countTotalThreadsStarted=81
process.1.jvm.countClassesLoaded=3170
process.1.jvm.peakThreads=79
process.1.jvm.millisecondsGarbageCollection=1981
process.1.jvm.vMVersion=1.5.0_09-b03
process.1.keepalive.countConnections=32
process.1.keepalive.maxConnections=200
process.1.keepalive.countFlushes=0
process.1.keepalive.countRefusals=0
process.1.keepalive.countTimeouts=6
process.1.keepalive.countHits=686943
process.1.keepalive.secondsTimeout=30
process.1.threadPool.1.countQueued=0
process.1.threadPool.1.countThreadsIdle=1
process.1.threadPool.1.threadPoolId=NativePool
process.1.threadPool.1.maxThreads=128
process.1.threadPool.1.countThreads=1
process.1.threadPool.1.maxQueued=0
process.1.threadPool.1.peakQueued=0
process.1.threadPool.1.name=NativePool
process.1.threadPool.2.countQueued=0
process.1.threadPool.2.countThreadsIdle=1
process.1.threadPool.2.threadPoolId=my-custom-pool
process.1.threadPool.2.maxThreads=128
process.1.threadPool.2.countThreads=1
process.1.threadPool.2.maxQueued=0
process.1.threadPool.2.peakQueued=0
process.1.threadPool.2.name=my-custom-pool

仮想サーバーの統計情報を取得するには、次のコマンドを入力します。

./wadm get-virtual-server-stats --user=admin-user --password-file=admin-password-file --config= config-name --vs=virtual-server-name

node オプションが使用されていないため、この構文によって、この構成が配備されているすべてのノードにわたる仮想サーバーの全体的な統計情報が得られます。node オプションを使用すると、出力が 1 つのノードに制限されます。

配備されている Web アプリケーションの統計情報を取得するには、次のコマンドを入力します。

./wadm get-webapp-stats --user=admin-user --password-file= admin-password-file --config=config-name --node= node-name --vs=virtual-server-name --uri= URI

この構文によって、特定のインスタンスの特定の仮想サーバーに配備されている特定の Web アプリケーションの統計情報が取得されます。特定の構成について、その構成が配備されているすべてのノードにわたる Web アプリケーションの全体的な統計情報を取得するには、このコマンドを node オプションを指定せずに使用します。

次の例は、URI hello の出力を示しています。
```
countActiveSessions=1
countExpiredSessions=0
countJsps=1
countRejectedSessions=0
countReloadedJsps=1
countSessions=1
peakActiveSessions=1
secondsSessionAliveAverage=0
secondsSessionAliveMax=0
uri=/hello
vsName=myvs.sun.com
```

stats.xml を使用した現在のアクティビティーの監視

stats-xml を使用して統計情報を表示することもできます。この場合は、統計情報が XML 形式で表示されます。stats-xml の出力は XML 形式であるため、各種のツールを使用して統計情報を容易に解析できます。URI からの stats-xml 出力の表示 (これは有効にする必要がある)、または CLI からの stats-xml 出力の表示 (これはデフォルトで有効になっている) のどちらかが可能です。

管理コンソールから stats-xml URI を有効にする

stats-xml URI を有効にすると、ブラウザを経由してサーバーの XML 形式の統計情報にアクセスできます。stats-xml URI を使用する場合は、管理サーバーが実行されていなくても統計情報にアクセスできることに注意してください。また、stats-xml URI がアクティブになっていると、アクセスを拒否するための予防策を取らないかぎり、ユーザーもサーバーの統計情報を表示できるようになります。

「共通操作」ページで、左側のプルダウンメニューから構成を選択します。

右側のプルダウンメニューから仮想サーバーを選択し、「仮想サーバーを編集」をクリックします。

「サーバー設定」タブで、「監視設定」サブタブをクリックします。

「XML レポート」の「有効」チェックボックスを選択します。

URI を指定します。たとえば、/stats-xml と入力します。

「保存」をクリックします。

構成を配備します。

stats-xml URI にアクセスします。次に例を示します。

http://yourhost: port/stats-xml

統計情報が XML 形式で表示されます。

CLI から stats-xml URI を有効にする

次のコマンドを使用して stats-xml を有効にします。

./wadm enable-stats-xml --user=admin-user --password-file= admin-password-file [--uri-prefix=prefix]--config= config-name --vs=virtual-server-name

uri-prefix オプションを使用して stats-xml URI を設定します。

wadm deploy-config コマンドを使用して構成を配備します。

stats-xml URI にアクセスします。次に例を示します。

http://yourhost :port/stats-xml

統計情報が XML 形式で表示されます。

URI で表示される stats-xml 統計情報を制限する

stats-xml URI を変更することにより、その URI で表示されるデータを制限できます。

情報を制限するように stats-xml URI を変更するには、各要素を 0 または 1 に設定します。0 に設定された要素は、stats-xml 出力には表示されません。次に例を示します。

http:// yourhost:port /stats-xml?thread=0&process=0

この構文では、stats-xml 出力が、スレッドとプロセスの統計情報を含まないように制限されます。デフォルトでは、すべての統計情報が有効になっています (1 に設定される)。

ほとんどの統計情報はサーバーレベルで表示できますが、一部の統計情報はプロセスレベルで表示できます。

stats-xml を制限するには、次の構文要素を使用します。
- cache-bucket
- connection-queue
- connection-queue-bucket (プロセスレベル)
- cpu-info
- dns-bucket
- jdbc-resource-bucket
- keepalive-bucket
- process
- profile
- profile-bucket (プロセスレベル)
- request-bucket
- servlet-bucket
- session-replication
- thread
- thread-pool
- thread-pool-bucket (プロセスレベル)
- virtual-server
- web-app-bucket

CLI から stats-xml 出力を表示する

URI に加えて、コマンド行インタフェース経由でも stats-xml 出力にアクセスできます。これはデフォルトで有効になっています。URI 経由の stats-xml 出力の表示とは異なり、コマンド行で stats-xml 出力を表示するには、管理サーバーが実行されている必要があります。ただし、要求を処理するスレッドがサーバー内で (たとえば、ビジー状態のために) ハングアップしており、URI を使用できない場合でも、引き続き CLI 経由で stats-xml 出力にアクセスできます。

コマンド行インタフェース経由で stats-xml 出力を表示するには、次のコマンドを入力します。

./wadm get-stats-xml --user=admin-user --password-file= admin-password-file --config=config-name --node= node-name

perfdump を使用した現在のアクティビティーの監視

perfdump ユーティリティーは Web Server に組み込まれた Server Application Function (SAF) であり、Web Server の内部統計情報からさまざまなパフォーマンスデータを収集し、ASCII テキストで表示します。perfdump 出力には、コマンド行の統計情報または管理コンソールで表示可能なすべての統計情報は表示されませんが、依然として便利なツールです。たとえば、管理サーバーが実行されていない場合でも、引き続き perfdump を使用できます。CLI 経由の perfdump 出力の表示 (これはデフォルトで有効になっている)、または URI 経由の perfdump 出力の表示 (これは有効にする必要がある) のどちらかが可能です。URI を有効にする場合は、perfdump URI へのアクセスを制御してください。そうしないと、ユーザーがその URI を表示できるようになります。

perfdump ユーティリティーでは、統計情報が統合されます。単一のプロセスを監視するのではなく、統計情報をプロセス数で乗算するため、サーバーの全体像を正確に把握することができます。

perfdump ユーティリティーで表示される情報のチューニングについては、「監視データに基づくサーバーのチューニング」を参照してください。

管理コンソールから perfdump URI を有効にする

管理コンソール経由で、仮想サーバーの perfdump URI を有効にすることができます。

注 –

perfdump で表示される統計情報は、そのサーバー全体の情報です。ある仮想サーバーで perfdump を有効にすると、個別の仮想サーバーではなく、サーバー全体の統計情報が表示されます。

「共通操作」で、構成を選択します。

仮想サーバーを選択し、「仮想サーバーを編集」をクリックします。

「監視設定」タブをクリックします。

「プレーンテキストレポート」の「有効」チェックボックスを選択します。

レポートにアクセスするための URI を指定します。たとえば、/.perf とします。

「保存」をクリックします。

構成を配備します。

perfdump にアクセスするには、仮想サーバー上の URI にアクセスします。

次に例を示します。http://localhost:80/.perf

perfdump 統計情報を要求し、統計情報がブラウザで自動的に更新される頻度 (秒) を指定できます。次の例では、更新が 5 秒ごとに設定されています。

http:// yourhost/.perf?refresh=5

CLI から perfdump URI を有効にする

次のコマンドを使用して stats-xml を有効にします。

./wadm enable-perfdump --user=admin-user --password-file= admin-password-file [--uri=uri]--config= config-name--vs=virtual-server-name

URI オプションを使用して pefdump URI を設定します。

wadm deploy-config コマンドを使用して構成を配備します。

perfdump にアクセスするには、仮想サーバー上の URI にアクセスします。

次に例を示します。http://localhost:80/.perf

perfdump 統計情報を要求し、統計情報がブラウザで自動的に更新される頻度 (秒) を指定できます。次の例では、更新が 5 秒ごとに設定されています。

http:// yourhost/.perf?refresh=5

CLI から perfdump データを表示する

URI に加えて、コマンド行インタフェース経由でも perfdump 出力にアクセスできます。これはデフォルトで有効になっています。URI 経由の perfdump 出力の表示とは異なり、コマンド行で perfdump 出力を表示するには、管理サーバーが実行されている必要があります。ただし、要求を処理するスレッドがサーバー内で (たとえば、ビジー状態のために) ハングアップしており、URI を使用できない場合でも、引き続き CLI 経由で perfdump 出力にアクセスできます。

コマンド行インタフェース経由で perfdump 出力を表示するには、次のコマンドを入力します。

./wadm get-perfdump --user=admin-user --password-file= admin-password-file --config=config-name --node= node-name

この出力は、コマンドウィンドウに表示されます。

サンプルの perfdump 出力

次に perfdump の出力例を示します。

webservd pid: 29133

Sun Java System Web Server 7.0 B07/13/2006 17:09 (SunOS DOMESTIC)

Server started Fri Jul 14 14:34:15 2006
Process 29133 started Fri Jul 14 14:34:17 2006

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            2/237/1352
Total Connections Queued                   67364017
Average Queue Length (1, 5, 15 minutes)    4.52, 4.73, 4.85
Average Queueing Delay                     13.63 milliseconds

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

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

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

Server cache disabled

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0
TestPool:
Idle/Peak/Limit               5/5/10
Work Queue Length/Peak/Limit  0/0/15

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

Async DNS disabled

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:               62647125
Request processing time:    0.0343  2147687.2500

default-bucket (Default bucket)
Number of Requests:                     62647125    (100.00%)
Number of Invocations:                3374170785    (100.00%)
Latency:                    0.0008    47998.2500    (  2.23%)
Function Processing Time:   0.0335  2099689.0000    ( 97.77%)
Total Response Time:        0.0343  2147687.2500    (100.00%)

Sessions:
-----------------------------------------------------------------------------------------------------------
Process  Status    Client     Age  VS          Method URI                                      Function

29133    response  192.6.7.7  115  https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  8    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  4    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  10.5.8.19  4    https-test  GET   /perf                                     service-dump
29133    response  192.6.7.7  3    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  3    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  2    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  2    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  2    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  192.6.7.7  2    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    request   192.6.7.7  0                                                                  
29133    request   192.6.7.7  0                                                                  
29133    request   192.6.7.7  0                                                                  
29133    request   192.6.7.7  0                                                                  
29133    request   192.6.7.7  0                                                                  
29133    response  192.6.7.7  0    https-test  GET   /file1.shtml                              shtml_send
29133    request   192.6.7.7  0                                                                     
29133    request   192.6.7.7  0                                                                     
29133    response  192.6.7.7  0    https-test  GET   /find-pathinfo-forward/pathinfo.pl/p/info send-cgi
29133    request   192.6.7.7  0                                                                     
29133    updating  192.6.7.7                                                                        
29133    updating  192.6.7.7                                                                         
29133    updating  192.6.7.7                                                                         
29133    updating  192.6.7.7                                                                         
.
.
.

パフォーマンスバケットの使用

パフォーマンスバケットを使用すると、バケットを定義し、それらのバケットをさまざまなサーバー関数にリンクできます。これらの関数のいずれかを呼び出すごとに、サーバーは統計データを収集し、それをバケットに追加します。たとえば、send-cgi と service-j2ee はそれぞれ、CGI と Java サーブレットの要求にサービスを提供するために使用される関数です。2 つのバケットを定義して CGI とサーブレットの要求に対して別々のカウンタを保持するか、または両方のタイプの動的コンテンツに対する要求をカウントするバケットを 1 つ作成することができます。この情報を収集するためにかかる負担は最小限で済み、サーバーパフォーマンスへの影響も通常はわずかです。この情報へはあとで perfdump ユーティリティーを使用してアクセスできます。バケット内には、次の情報が格納されます。

バケットの名前: この名前によって、バケットが関数に関連付けられます。
説明: このバケットが関連付けられている関数の説明。
この関数に対する要求の数: この関数の呼び出しを引き起こした要求の総数。
関数が呼び出された回数: 1 つの要求に対して複数回実行される関数もあるため、この回数は、関数に対する要求の数とは一致しない可能性があります。
関数の待ち時間またはディスパッチ時間: サーバーが関数を呼び出すためにかかった時間。
関数の時間: 関数自体で費やされた時間。

default-bucket は、サーバーで事前に定義されています。。ここには、ユーザーが定義したどのバケットにも関連付けられていない関数の統計情報が記録されます。

構成

パフォーマンスバケットのすべての設定情報を、magnus.conf および obj.conf ファイルに指定してください。自動的に有効になるのは、default-bucket だけです。

最初に、パフォーマンス統計の収集と perfdump を有効にする必要があります。

次の例は、magnus.conf で新しいバケットを定義する方法を示しています。

Init fn="define-perf-bucket" name="acl-bucket" description="ACL bucket"

Init fn="define-perf-bucket" name="file-bucket" description="Non-cached responses"

Init fn="define-perf-bucket" name="cgi-bucket" description="CGI Stats"

前述の例では、次の 3 つのバケットを作成しています。acl-bucket、file-bucket、および cgi-bucket。これらのバケットを関数に関連付けるには、パフォーマンスを測定する obj.conf 関数に bucket=bucket-name を追加します。

例

PathCheck fn="check-acl" acl="default" bucket="acl-bucket"
...
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" 
fn="send-file" bucket="file-bucket"
...
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi" bucket="cgi-bucket"
</Object>

詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』の「The bucket Parameter」を参照してください。

パフォーマンスレポート

バケットのサーバー統計情報には、perfdump ユーティリティーを使用してアクセスできます。パフォーマンスバケット情報は、perfdump によって返されるレポートの最後のセクションに配置されています。

レポートには次の情報が含まれています。

平均 (Average)、合計 (Total)、パーセント (Percent) の各列には、要求された各統計情報のデータが表示されます。
要求処理時間 (Request Processing Time) はサーバーがそれまでに受信したすべての要求を処理するために要した合計時間です。
要求数 (Number of Requests) は関数の要求の合計数です。
呼び出し数 (Number of Invocations) は、関数が呼び出された合計回数です。1 つの要求の処理中に、関数が何度も呼び出される場合があるため、呼び出された回数は要求の数とは異なります。この行のパーセント列は、すべてのバケットの呼び出し回数の合計に基づいて計算されます。
遅延 (Latency) は Web Server が関数の呼び出しに要した時間 (秒) です。
関数処理時間 (Function Processing Time) は Web Server が関数の処理に費やした時間 (秒) です。Function Processing Time と Total Response Time のパーセンテージは、Request Processing Time の合計に基づいて計算されます。
合計応答時間 (Total Response Time) は Function Processing Time と Latency の合計 (秒) です。

perfdump で表示可能なパフォーマンスバケット情報の例を次に示します。

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:               62647125
Request processing time:    0.0343  2147687.2500

default-bucket (Default bucket)
Number of Requests:                     62647125    (100.00%)
Number of Invocations:                3374170785    (100.00%)
Latency:                    0.0008    47998.2500    (  2.23%)
Function Processing Time:   0.0335  2099689.0000    ( 97.77%)
Total Response Time:        0.0343  2147687.2500    (100.00%)

Java ES 監視コンソールを使用した現在のアクティビティーの監視

Web Server 管理コンソールとコマンド行インタフェースで表示可能な統計情報は、Java ES 監視コンソールでも表示できます。情報は同じですが、CMM (Common Monitoring Data Model) を使用した別の形式で提供されます。このマニュアルでは、Web Server で利用可能なツールを使用した監視について説明していますが、Java ES 監視ツールを使用してサーバーを監視することもできます。Java ES 監視ツールの使用の詳細については、『Sun Java Enterprise System 5 Monitoring Guide 』を参照してください。使用する監視方法には関係なく、サーバーのチューニングには同じ設定を使用します。