test

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

第 3 章 Application Server のチューニング

この章では、Application Server をチューニングしてパフォーマンスを最適化する方法をいくつか説明します。具体的な内容は次のとおりです。

配備の設定

配備の設定はパフォーマンスに大きな影響を及ぼします。パフォーマンスを最適化するために配備を設定する際には、次の各指針に従ってください。

自動配備を無効にする

自動配備を有効にすることは、開発環境では便利ですが、配備に悪影響を及ぼします。本番システムでは、パフォーマンスを最適化するために自動配備を無効にしてください。自動配備が有効になっている場合、「再読込みのポーリング間隔」設定がパフォーマンスに大きな影響を及ぼす可能性があります。

管理コンソールで自動配備を無効にするには、「スタンドアロンインスタンス」>「server (管理サーバー)」の下にある「詳細/アプリケーション設定」タブを選択します。

プリコンパイルされた JavaServer Pages を使用する

JSP ファイルのコンパイルはリソース集約型であり、実行に長い時間がかかります。アプリケーションをサーバーに配備する前に JSP ファイルをプリコンパイルしておけば、アプリケーションのパフォーマンスが改善されます。そのようにした場合、結果として得られるサーブレットクラスファイルのみが配備されます。

管理コンソールまたは deploytool を使えば、アプリケーションを配備するときに JSP ファイルのプリコンパイルを指定できます。また、管理コンソールで「スタンドアロンインスタンス」>「server (管理サーバー)」の下にある「詳細/アプリケーション設定」タブを使えば、配備済みのアプリケーションに対する JSP ファイルのプリコンパイルを指定することもできます。

アプリケーションの動的再読み込みを無効にする

動的再読み込みを有効にすると、サーバーは配備されているアプリケーションの変更を定期的にチェックし、変更のあるアプリケーションを自動的に再読み込みします。動的再読み込みは開発環境向けのものであり、さらにセッション持続との互換性もありません。パフォーマンスを改善するには、クラスの動的再読み込みを無効にします。

管理コンソールで、すでに配備されているアプリケーションのクラスの動的再読み込みを無効にするには、「スタンドアロンインスタンス」>「server (管理サーバー)」の下にある「詳細/アプリケーション設定」タブを選択します。

ロガーの設定

Application Server は、インスタンスのログディレクトリ appserver-root/domains/domain-name/logs 内のログファイルに、ログメッセージと例外スタックトレース出力を書き込みます。当然ながら、ログアクティビティーのボリュームは、ベンチマークの状況下では特に、サーバーのパフォーマンスに影響を与える可能性があります。

一般的な設定

一般に、システムログに情報を書き込むとパフォーマンスが若干低下します。また、ログレベルを上げたりファイルローテーションの制限や時間制限を減らしたりすることでディスクアクセスが増大しても、アプリケーションのパフォーマンスが低下します。

また、任意のカスタムログハンドラがネットワークファイルシステムなどの低速デバイスにログを記録しないように十分に注意してください。なぜなら、それはパフォーマンスに悪影響を与える可能性があるからです。

ログレベル

管理コンソールでサーバーやそのサブシステムのログレベルを設定するには、「ロガーの設定」ページの「ログレベル」タブを選択します。このページでは、サーバー (「ルート」と表示) のデフォルトログレベル、EJB コンテナ、MDB コンテナ、Web コンテナ、クラスローダー、JNDI ネーミングシステム、セキュリティーなどの javax.enterprise.system サブシステム (「サーバー」と表示) のデフォルトログレベル、および個々のサブシステムごとのデフォルトログレベルを指定できます。

ログレベルは、最大のログ情報を提供する FINEST から、通常のプログラム実行の妨げとなるイベントのみをログに記録する SEVERE まで変化します。デフォルトのログレベルは INFO です。個々のサブシステムのログレベルは「サーバー」設定よりも優先されますが、その「サーバー」設定は「ルート」設定よりも優先されます。

たとえば、MDB コンテナは、サーバーのデフォルトとは異なるレベルでログメッセージを生成できます。より多くのデバッグメッセージを取得するには、ログレベルを FINE、FINER、または FINEST に設定します。通常の条件下で最高のパフォーマンスを得るには、ログレベルを WARNING に設定します。ベンチマークの条件下では通常、ログレベルを SEVERE に設定するのが適切です。

Web コンテナの設定

管理コンソールで Web コンテナのプロパティーを設定するには、「設定」>「config-name」>「Web コンテナ」を選択します。

セッションプロパティー: セッションタイムアウト

セッションタイムアウトは、ユーザーがセッションを明示的に無効にしなかった場合にサーバーがそのセッションをどれだけの期間維持するかを決定します。デフォルトは 30 分です。アプリケーションの要件に応じてこの値を調整してください。セッションタイムアウトに非常に大きな値を設定すると、サーバーがセッションストア内に維持すべきセッションの数が多くなりすぎ、パフォーマンスが劣化する可能性があります。一方、非常に小さな値を設定すると、サーバーがセッションを回収するタイミングが早くなりすぎる可能性があります。

マネージャープロパティー: 取得間隔

取得間隔を変更するとパフォーマンスが改善される可能性がありますが、使用するセッションやビジネスロジックの性質を考慮しないでこの値を設定すると、時間に基づく持続周期の場合は特に、データの不整合が発生する可能性があります。

たとえば、取得間隔を 60 秒に設定すると、セッションデータの値が 60 秒ごとに記録されます。このとき、クライアントが 20 秒ごとにサーブレットにアクセスして値を更新すると、不整合が発生します。

たとえば、次のようなオンラインオークションのシナリオを考えます。

JSP の動的再読み込みを無効にする

本番システムでは、Web コンテナのパフォーマンスを改善するために、JSP の動的再読み込みを無効にします。そうするには、インスタンスごとに config ディレクトリ内の default-web.xml ファイルを編集します。JSP ファイルのサーブレット定義を次のように変更してください。

<servlet>
    <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
    ...
    <load-on-startup>3</load-on-startup>
</servlet>

EJB コンテナの設定

EJB コンテナには、パフォーマンスに影響を与える設定が数多くあります。EJB コンテナの実行やパフォーマンスを追跡するには、ほかの領域の場合と同じく、EJB コンテナの監視機能を使用します。

EJB コンテナの監視

EJB コンテナの監視はデフォルトで無効になっています。管理コンソールで監視を有効にするには、「設定」>「config-name」>「監視」を選択します。すべての配備済み EJB コンポーネント、EJB プール、および EJB キャッシュを監視するには、「EJB コンテナ」の監視レベルを「低」に設定します。EJB ビジネスメソッドも監視するには、この監視レベルを「高」に設定します。

EJB コンテナのチューニング

EJB コンテナは、EJB コンポーネントをキャッシュやプールに格納することでパフォーマンスの向上を図ります。キャッシュやプールのプロパティーを調整すれば、EJB コンテナのパフォーマンスを大幅に改善できます。EJB のキャッシュやプールの設定を行うには、管理コンソールの「設定」>「config-name」>「EJB コンテナ (EJB 設定)」を選択します。

プール設定がステートレスセッション Beans とエンティティー Beans で使用できるのに対し、キャッシュ設定はステートフルセッション Beans とエンティティー Beans で使用できます。

EJB のプール処理とキャッシュ処理の概要

ステートレスセッション Beans とエンティティー Beans はどちらも、サーバーのパフォーマンスを改善する目的でプール内に格納できます。さらに、ステートフルセッション Beans とエンティティー Beans はどちらも、パフォーマンスを改善する目的でキャッシュ内に格納できます。

表 3–1 Bean タイプ別のプール処理またはキャッシュ処理

Bean 型 

プール 

キャッシュ 

ステートレスセッション 

可 

不可 

ステートフルセッション 

不可 

可 

エンティティー 

可 

可 

プール Bean とキャッシュ Bean の違いは、プール Beans はどれも等価であり、互いに区別できない、という点にあります。これに対し、キャッシュ Beans には、ステートフルセッション Beans の場合は対話状態が格納され、エンティティー Beans の場合は主キーが関連付けられます。エンティティー Beans は、ejbActivate() 呼び出し時にプールから削除されてキャッシュに追加され、ejbPassivate() 呼び出し時にキャッシュから削除されてプールに追加されます。ejbActivate() は、必要なエンティティー Bean がキャッシュ内に存在しない場合に、コンテナによって呼び出されます。ejbPassivate() は、キャッシュがその設定された上限を超えた場合に、コンテナによって呼び出されます。

注 –

Sun Java Studio を使って EJB コンポーネントを開発および配備する場合、個々の Bean 記述子の設定を、Bean プールや Bean キャッシュ向けに編集する必要があります。これらの設定は、本番レベルの配備に適していない可能性があります。

EJB プールのチューニング

プール内の Bean は、EJB のライフサイクルにおけるプール状態を表します。つまり、その Bean は ID を持ちません。Bean をプール内に格納することの利点は、要求を処理するための Bean の作成時間を短縮できることにあります。このコンテナには、リクエストパスで Bean の作成時間を短縮できるよう、プールオブジェクトをバックグラウンドで作成するためのメカニズムが備わっています。

ステートレスセッション Beans とエンティティー Beans が EJB プールを使用します。ステートレスセッション Beans の使用方法やサーバーが処理するトラフィックの量に注意しながらプールサイズの調整を行い、Beans の過剰な作成や削除が発生しないようにしてください。

EJB のプール設定

ある特定の EJB コンポーネントで、EJB コンテナのキャッシュ設定を上書きするキャッシュ設定を指定するには、その EJB コンポーネントの sun-ejb-jar.xml 配備記述子の <bean-pool> 要素を使用します。

EJB のプール設定は次のとおりです。

EJB キャッシュのチューニング

キャッシュ内の Bean は、EJB のライフサイクルにおける実行可能状態を表します。これは、その Bean に ID (主キーやセッション ID など) が関連付けられていることを意味します。

キャッシュの外側に移動する Beans は、EJB のライフサイクルに従って非活性化するか破棄する必要があります。非活性化された Bean をキャッシュ内に戻すには、その Bean を活性化する必要があります。エンティティー Beans は一般に、データベース内に格納され、何らかの形式のクエリー言語セマンティクスを使ってデータの読み込みや格納を行います。セッション Beans は、非活性化時にディスクまたはデータベースに格納するために直列化する必要があるほか、活性化時にも同様に直列化復元を行う必要があります。

こうしたキャッシュ内の「実行可能」Beans を使用する着信要求はすべて、作成、ID 設定、および場合によっては活性化のオーバーヘッドを回避することができます。したがって、理論上は、できるだけ多くの Beans をキャッシュに書き込むのが良いことになります。ところが、キャッシュへの書き込みには次のような欠点があります。

アプリケーションによるステートフルセッション Beans やエンティティー Beans の使用方法やサーバーが処理するトラフィックの量に注意しながら EJB のキャッシュサイズおよびタイムアウト設定のチューニングを行い、活性化や非活性化の回数が最小限に抑えられるようにしてください。

EJB のキャッシュ設定

ある特定の EJB コンポーネントで、EJB コンテナのキャッシュ設定を上書きするキャッシュ設定を指定するには、その EJB コンポーネントの sun-ejb-jar.xml 配備記述子の <bean-cache> 要素を使用します。

EJB のキャッシュ設定は次のとおりです。

最大キャッシュサイズ

キャッシュ内の Beans の最大数。この設定は 1 より大きくしてください。デフォルト値は 512 です。値ゼロはキャッシュが無制限であることを示しますが、これは、キャッシュのサイズが「キャッシュアイドルタイムアウト」と「キャッシュのサイズ変更量」によって制御されることを意味します。EJB 配備記述子の対応する属性は、max-cache-size です。

キャッシュのサイズ変更量

キャッシュがサーバーによって処理されているときに作成または削除される Beans の数。有効な値はゼロから MAX_INTEGER までであり、デフォルトは 16 です。EJB 配備記述子の対応する属性は、resize-quantity です。

削除タイムアウト

ステートフルセッション Bean が非活性化状態 (バックアップストア内でのアイドル状態) でいられる時間。ある Bean へのアクセスがこの期間が過ぎたあとも発生しなかった場合、その Bean はバックアップストアから削除され、クライアントからアクセスできなくなります。デフォルトは 60 分です。EJB 配備記述子の対応する属性は、removal-timeout-in-seconds です。

選択内容の削除ポリシー

キャッシュからオブジェクトを削除するのに使用されるアルゴリズム。EJB 配備記述子の対応する属性は、victim-selection-policy です。選択肢は次のとおりです。

  • NRU (最近使用されていない): これがデフォルトですが、これは実際には擬似乱数選択ポリシーです。

  • FIFO (ファーストインファーストアウト)

  • LRU (最近の使用頻度がもっとも低い)

キャッシュアイドルタイムアウト

ステートフルセッション Bean またはエンティティー Bean がキャッシュ内でアイドル状態でいられる時間の最大値。この時間が経過した Bean は、非活性化されてバックアップストア内に格納されます。デフォルト値は 600 秒です。EJB 配備記述子の対応する属性は、cache-idle-timeout-in-seconds です。

更新間隔

読み取り専用 Bean がデータソースから更新される頻度。ゼロ (0) は、Bean が決して更新されないことを意味します。デフォルトは 600 秒です。EJB 配備記述子の対応する属性は、refresh-period-in-seconds です。注意: この設定に対応するカスタムフィールドは、管理コンソール内に存在しません。これを設定するには、「追加プロパティー」セクションの「プロパティーを追加」ボタンを使用してください。

個々の EJB コンポーネントのプールおよびキャッシュ設定

sun-ejb-jar.xml 配備記述子に含まれる個々の EJB のプールおよびキャッシュ設定は、EJB コンテナの設定よりも優先されます。次の表は、キャッシュおよびプール設定の一覧を、EJB コンポーネントのタイプ別に示したものです。

表 3–2 EJB のキャッシュおよびプール設定

 

キャッシュ設定 

プール設定 

Bean のタイプ 

cache-resize-quantity 

max- cache-size 

cache-idle-timeout-in-seconds 

removal- timeout- in- seconds 

victim-selection- policy 

refresh-period-in-seconds 

steady-pool-size 

pool-resize-quantity 

max-pool-size 

pool-idle-timeout-in- seconds 

ステートフルセッション 

X 

X 

X 

X 

X 

         

ステートレスセッション 

           

X 

X 

X 

X 

エンティティー 

X 

X 

X 

X 

X 

 

X 

X 

X 

X 

エンティティー (読み取り専用) 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

メッセージ駆動型 Bean 

             

X 

X 

X 

コミットオプション

コミットオプションは、ある EJB コンポーネントがトランザクションを完了したときに EJB コンテナによって実行されるアクションを制御します。コミットオプションはパフォーマンスに大きな影響を及ぼします。

コミットオプションで使用可能な値には次の 2 つがあります。

オプション B では、ejbAcivate() と ejbPassivate() の呼び出しを避けられます。このため、ほとんどの場合、オプション C の場合よりもパフォーマンスが良くなります。なぜなら、プールからオブジェクトを取得したりオブジェクトを解放してプールに戻したりするオーバーヘッドの一部を回避できるからです。

ただし、オプション C のほうがパフォーマンスが良くなる場合もあります。キャッシュ内の Beans がほとんど再利用されず、Beans が継続的にキャッシュに追加されるようであれば、Beans をキャッシュに書き込む意味がありません。オプション C が使用される場合、コンテナは、メソッド呼び出し後やトランザクション完了時に、Beans をキャッシュに書き込む代わりにプールに戻します。このオプションでは、インスタンスの再利用がより効率的に行われるほか、JVM 内のライブオブジェクトの数が減少するのでガベージコレクションの高速化も図れます。

最適なコミットオプションの決定

コミットオプション B、コミットオプション C のどちらを使用すべきかを決定するには、まず、Bean の監視コマンドを使ってキャッシュヒット数を調べます。キャッシュヒット数がキャッシュミス数を大幅に上回っている場合は、オプション B が適切な選択肢となります。最良の結果を得るためには、さらに max-cache-size と cache-resize-quantity を変更する必要がある可能性もあります。

キャッシュヒット数が極めて低く、かつキャッシュミス数が非常に多い場合、アプリケーションが Bean インスタンスを再利用できていないので、max-cache-size を使ってキャッシュサイズを増やしても効果はありません (アクセスパターンが同じままであると仮定した場合)。この場合はコミットオプション C を使用することができます。キャッシュヒット数とキャッシュミス数にあまり大きな違いがない場合には、max-cache-size をチューニングし、場合によっては cache-idle-timeout-in-seconds もチューニングしてください。

Java メッセージサービスの設定

Java Message Service (JMS) がローカルシステム上、リモートシステム上のいずれに存在するかを決定する「型」属性は、パフォーマンスに影響を与えます。パフォーマンスは、ローカルの JMS のほうがリモートの JMS よりも高くなります。ただし、リモートクラスタはフェイルオーバー機能を備えており、管理も一括して行えます。したがって、リモートの JMS を使用することには別の利点が見いだせる可能性があります。JMS の使用方法の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。

トランザクションサービスの設定

トランザクションマネージャーを使えば、分散トランザクションのコミットおよびロールバックを行えます。

分散トランザクションシステムは、トランザクションアクティビティーをトランザクションログに書き込み、あとで回復を実行できるようにします。ただし、トランザクションログへの書き込みを行うと、パフォーマンスがある程度低下します。

トランザクションサービスの監視

トランザクションマネージャーの監視はデフォルトで無効になっています。管理コンソールでトランザクションサービスの監視を有効にするには、「設定」>「config-name」>「監視」を選択します。

また、次のコマンドを使って監視を有効にすることもできます。

set serverInstance.transaction-service.monitoringEnabled=true
reconfig serverInstance

監視情報の表示

トランザクションサービスの監視を有効にした場合、その結果を表示するには次のようにします。

トランザクションサービスに関する次の統計が収集されます。

次に、asadmin を使用した場合の出力のサンプルを示します。

********** Stats for JTS ************
 total-tx-completed = 244283
 total-tx-rolled-back = 2640
 total-tx-inflight = 702
 isFrozen = False
 inflight-tx =
 Transaction Id , Status, ElapsedTime(msec)
 000000000003C95A_00, Active, 999

トランザクションサービスのチューニング

回復よりもパフォーマンスが格段に重要であるような場合に、このプロパティーを使えば、トランザクションロギングを無効にすることができます。このプロパティーはデフォルトでは、サーバー設定内に存在しません。

分散トランザクションロギングの無効化

管理コンソールで分散トランザクションロギングを無効にするには、「設定」>「config-name」>「トランザクションサービス」を選択します。「プロパティーを追加」をクリックし、次のように指定します。

再起動で回復 (自動回復)

管理コンソールで「再起動で回復」属性を設定するには、「設定」>「config-name」>「トランザクションサービス」を選択します。「回復」チェックボックスをクリックして true (チェックされた状態、デフォルト) または false (チェックが解除された状態) に設定します。

また、asadmin を使って自動解除を設定することもできます。次に例を示します。

asadmin set server1.transaction-service.automatic-recovery=false

「再起動で回復」が true の場合、「分散トランザクションロギングの無効化」属性の値に関係なく、サーバーは常にトランザクションロギングを実行します。

「再起動で回復」が false の場合は次のようになります。

キーポイント間隔

「キーポイント間隔」は、完了したトランザクションのエントリをログファイルから削除する頻度を決定します。キーポイント処理を使えば、プロセスログが無制限に増大するのを防ぐことができます。

頻繁なキーポイント処理はパフォーマンスに悪影響を及ぼします。キーポイント間隔のデフォルト値は 2048 ですが、ほとんどの場合はこれで十分です。

HTTP サービスの設定

クライアント要求を処理する HTTP サーバーインスタンスの監視とチューニングは、Application Server のピーク時のパフォーマンスを確保するうえで重要となります。

HTTP サービスの監視

HTTP サービスの監視統計を有効にするには、管理コンソール、asadmin のいずれかを使用します。管理コンソールの場合、監視レベル (「低」または「高」) は HTTP サービスの監視に何の効果も持ちません。

asadmin の場合、利用可能な監視パラメータを一覧表示するには、次のコマンドを使用します。

list --user admin --port 4848
 -m server-instance-name.http-service.*

ここで、server-instance-name はサーバーインスタンスの名前です。

値を取得するには、次のコマンドを使用します。

get --user admin --port 4848 -m server.http-service.parameter-name.*

ここで、parameter-name は監視するパラメータの名前です。

統計の収集はデフォルトで有効になっています。これを無効にするには、次のプロパティーを domain.xml に追加し、サーバーを再起動します。

<property name="statsProfilingEnabled" value="false" />

統計の収集を無効にするとパフォーマンスが向上します。

管理コンソールでも監視統計を表示できます。この情報は次のカテゴリに分けられます。

一般的な HTTP 統計 (http-service)

管理コンソールが提供するパフォーマンス関連の HTTP 統計は、次のとおりです。

DNS キャッシュ情報 (dns)

DNS キャッシュでは、IP アドレスと DNS 名がキャッシュされます。サーバーの DNS キャッシュはデフォルトで無効になっています。Web ベースの管理インタフェースの「監視」の下にある「プロセス ID すべての DNS 統計」ページでは、次の統計が表示されます。

Enabled

DNS キャッシュが無効になっていると、この節の残りの部分は表示されません。

デフォルトで、DNS キャッシュは無効になっています。管理コンソールで DNS キャッシュを有効にするには、DNS の値を「サーバーにアクセスするクライアントに対して DNS 検索を実行する」に設定します。

CacheEntries (CurrentCacheEntries / MaxCacheEntries)

キャッシュエントリの現在の数と最大数。単一のキャッシュエントリは、単一の IP アドレスまたは単一の DNS 名の検索を表します。キャッシュのサイズは、Web サイトに同時にアクセスするクライアントの最大数を格納できるだけの大きさにしてください。キャッシュサイズの設定値が大きすぎるとメモリーが無駄に消費され、パフォーマンスが劣化します。

DNS キャッシュの最大サイズを設定するには、「パフォーマンスチューニング」ページの「DNS キャッシュのサイズ」フィールドの値を入力または変更します。

HitRatio

ヒット率は、キャッシュヒット数をキャッシュ検索数で割ったものです。

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

注 –

サーバー上で DNS 検索を無効にすると、ホスト名の制限が正常に機能しなくなるほか、ログファイル内でホスト名の代わりに IP アドレスが表示されます。

DNS エントリのキャッシュへの書き込み

DNS エントリをキャッシュに書き込むかどうかを指定することもできます。DNS キャッシュが有効になっていると、サーバーは、ホスト名の情報を受信したあと、その情報を格納することができます。その後、サーバー上でそのクライアントの情報が必要になった場合、その情報はキャッシュ内に存在しているため、再度クエリーを実行しなくてもその情報を利用できます。DNS キャッシュのサイズと DNS キャッシュエントリの有効期間を指定します。DNS キャッシュには 32 件から 32768 件までのエントリを格納できます。デフォルト値は 1024 です。キャッシュエントリが期限切れになるまでの時間の値は、1 秒から 1 年までの範囲で秒単位で指定できます。デフォルト値は 1200 秒 (20 分) です。

DNS 検索を非同期に制限する

DNS 検索はリソース集約型であるため、サーバープロセス内では使用しないでください。DNS 検索を含める必要がある場合には、検索を非同期にしてください。

Enabled

非同期 DNS が無効になっていると、この節の残りの部分は表示されません。

NameLookups

サーバー起動後に実行された名前検索 (DNS 名から IP アドレス) の数。この設定はチューニング不可能です。

AddrLookups

サーバー起動後に実行されたアドレス検索 (IP アドレスから DNS 名) の数。この設定はチューニング不可能です。

LookupsInProgress

現在実行中の検索の数。

接続キュー

ファイルキャッシュ情報 (file-cache)

ファイルキャッシュには静的コンテンツが格納されるため、サーバーは静的コンテンツに対する要求をすばやく処理できます。file-cache セクションは、ファイルキャッシュの使用状況に関する統計を提供します。

ファイルキャッシュのチューニング方法の詳細については、「HTTP ファイルキャッシュ」を参照してください。

キープアライブ (keep-alive)

管理コンソールが提供するパフォーマンス関連のキープアライブ統計は、次のとおりです。

スレッドプール (pwc-thread-pool)

管理コンソールが提供するスレッドプール統計は、次のとおりです。

HTTP サービスのチューニング

管理コンソールでは、HTTP サービスの設定は次のカテゴリに分けられています。

アクセスログ

ベンチマーク実行時にはアクセスロギングを無効にします。アクセスロギングはデフォルトで有効になっています。これを無効にするには、「HTTP サービス」で「プロパティーを追加」をクリックし、次のプロパティーを追加します。

設定可能なアクセスログのプロパティーは、次のとおりです。

要求処理

「HTTP サービス」ページの「要求処理」タブで、次の HTTP 要求処理設定を調整します。

スレッド数

「スレッド数」パラメータは、サーバーが処理できる同時要求の最大数を指定します。デフォルト値は 128 です。サーバーは、この要求スレッドの制限に達すると、アクティブ要求数がこの最大数を下回るまで、新しい要求の処理を遅らせます。この値を増やすと、HTTP 応答の待ち時間が短縮されます。

実際には、クライアントがサーバーに接続したあと、要求を完了しないことが頻繁に発生します。それらの場合、サーバーは、「要求タイムアウト」パラメータに指定された時間だけ待ちます。

また、一部のサイトでは、完了までに数分かかる高負荷のトランザクションが実行されます。これらの要因はどちらも、必要とされる最大同時要求数を押し上げます。多くの秒数のかかる要求を多数処理するサイトでは、最大同時要求数を増やさなければいけない可能性があります。

負荷と平均的な要求の処理時間に基づいて、スレッド数の値を調整します。一般に、アイドル CPU 時間と保留中の要求が存在している場合はこの数値を増やし、CPU が過負荷状態になっている場合はこの数値を減らします。HTTP 1.0 クライアント (または接続解除を頻繁に行う HTTP 1.1 クライアント) が多数存在している場合には、タイムアウト値を調整することで、接続を開いたままにしておく時間を短くします。

適切な要求スレッド数の値の範囲は、負荷によって 100 〜 500 になります。システムに余分な CPU サイクルが存在する場合には、スレッド数を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、スレッド数を増やすのをやめます。

初期スレッド数

「初期スレッド数」プロパティーは、サーバーが起動時に開始するスレッドの最小数を指定します。デフォルト値は 48 です。「初期スレッド数」は同時に実行可能なアクティブスレッドの最大数に対する強い制限値を表しますが、これがパフォーマンス上の障害になる可能性があります。

要求タイムアウト

「要求タイムアウト」プロパティーは、サーバーがあるクライアントへの接続を受け付けてからそのクライアントから情報を受け取るまでに待機する秒数を指定します。デフォルト設定は 30 秒です。ほとんどの状況下では、この設定を変更する必要はありません。これをデフォルトの 30 秒よりも小さい値に設定すると、スレッドをより早く解放できます。これをデフォルトの 30 秒よりも小さい値に設定すると、スレッドをより早く解放できる場合もあります。ただし、低速な接続のユーザーも切断してしまいます。

バッファー長

個々の要求処理スレッドがクライアントからの要求データを読み込むために使用するバッファーのサイズ (バイト)。

要求の実際のサイズに基づいてこの値を調整し、そのパフォーマンスへの影響を監視してください。ほとんどの場合はデフォルトで十分なはずです。要求のサイズが大きい場合はこのパラメータを増やしてください。

キープアライブ

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

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

システムに余分な CPU サイクルが存在する場合には、キープアライブ設定を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

パフォーマンスに影響を与える HTTP キープアライブ設定は、次のとおりです。

スレッド数

スレッド数は、キープアライブサブシステム内のスレッドの数を決定します。この設定は、システムのプロセッサ数の数倍になるように調整してください。たとえば、2 個の CPU を備えたシステムは、2 個または 4 個のキープアライブスレッドを持つことができます。

デフォルトは 1 です。ユーザー数や最大接続数が少ないサーバーでは、このデフォルトを変更しないでください。

最大接続数

最大接続数は、サーバーが維持するキープアライブ接続の最大数を制御します。指定可能な範囲はゼロから 32768 まであり、デフォルトは 256 です。

この設定は、サーバーが処理すると予想されるキープアライブ接続の数とサーバーの負荷に基づいて調整してください。なぜなら、この設定を増やすとリソース使用量も増え、待ち時間が長くなる可能性があるからです。

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

タイムアウト

タイムアウトは、サーバーが HTTP キープアライブ接続を開いたままで維持する最大時間 (秒) を決定します。クライアントはサーバーへの接続を開いたままに保つことができるため、1 つのサーバーへの複数の要求を、単一のネットワーク接続を使って処理できます。サーバーが処理できるオープン接続の数は限られているため、オープン接続の数が多すぎると、新しいクライアントが接続できなくなります。

タイムアウトのデフォルト値は 30 秒です。したがって、デフォルトでは、接続のアイドル状態が 30 秒を超えると、サーバーはその接続を閉じます。このパラメータの最大値は 300 秒 (5 分) です。

このパラメータの適切な値は、ある特定のクライアントからの各要求間の予想経過時間によって異なります。たとえば、クライアントからの要求頻度が多いことが予期される場合は、このパラメータを大きな値に設定します。同様に、クライアントからの要求頻度が少ないことが予期される場合は、このパラメータを小さな値に設定します。

キープアライブクエリー平均時間

キープアライブクエリー平均時間は、キープアライブ接続のポーリング間隔を指定します。このパラメータの値が n ミリ秒である場合、キープアライブ接続を要求したクライアントから見た応答時間は、0 ミリ秒から n ミリ秒までのオーバーヘッドを持ちます。

このパラメータのデフォルト値は 1 ミリ秒ですが、キープアライブ接続の予想同時負荷が 300 件未満である場合には、これで問題ありません。このデフォルト値を使用すると、同時負荷が高い場合にスケーラビリティーが極度に低下する恐れがあります。接続負荷の高いアプリケーションでは、このデフォルト値を増やしてください。

このパラメータを設定するには、asadmin を使用するか、あるいは管理コンソールの「HTTP サービス」ページで「プロパティーを追加」を選択し、次のように指定します。

キープアライブクエリー最大スリープ時間

キープアライブクエリー最大スリープ時間は、キープアライブ接続のポーリングによってさらなる要求の有無を確認したあとに待機する最大時間 (ミリ秒) を指定します。システムに余分な CPU サイクルが存在する場合には、このパラメータを段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

このパラメータを設定するには、asadmin を使用するか、あるいは管理コンソールの「HTTP サービス」ページで「プロパティーを追加」を選択し、次のように指定します。

接続プール

接続キュー情報は、キュー内のセッション数や接続が受け付けられるまでの平均遅延時間などを示します。

システムに余分な CPU サイクルが存在する場合には、接続プール設定を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

パフォーマンスに影響を与える接続プール設定は、次のとおりです。

最大保留カウント

最大保留カウントは、待機ソケット上で保留状態になっている接続の最大数を指定します。最大保留カウントを調整するのは、システムの負荷が非常に高い場合だけにしてください。低負荷から中程度の負荷の場合、デフォルトで問題ありません。

システムの動作を監視したあと、その結果に基づいて値を変更してください。そうでないと、サーバーは接続をドロップし始めます。バックログキューがいっぱいになった待機ソケット上で接続がタイムアウトすると、その接続は失敗します。最大保留カウントが制限に近づいた場合、高負荷下で接続のドロップが発生しないように、最大接続キューサイズを増やしてください。

キューサイズ

キューサイズは、サーバーが持つことのできる未処理の (まだ処理されていない) 接続の数を指定します。限られた数の要求処理スレッドを持つ、ユーザー数の多い高負荷システムでは、この設定を調整して大きな値にしてください。

注 –

接続キューサイズの設定を大きくしすぎると、サーバーのパフォーマンスが劣化する恐れがあります。その設計目的は、処理できない接続によってサーバーが過負荷状態に陥るのを防ぐことでした。サーバーが過負荷状態に陥っている場合に接続キューサイズを増やしても、要求処理の待ち時間が長くなり、接続キューが再度いっぱいになります。

送信バッファーサイズ

ソケットによって使用される送信バッファーのサイズ (バイト) を指定します。

受信バッファーサイズ

ソケットによって使用される受信バッファーのサイズ (バイト) を指定します。

送信バッファーサイズと受信バッファーサイズは、それぞれ出力バッファー、入力バッファー用として割り当てられるバッファーサイズのことです。これらのパラメータを調整するには、それらの値を規則的に増やし、そのパフォーマンスへの影響を監視します。パフォーマンスが飽和したら (あまり改善されなくなったら)、値を増やすのをやめます。

HTTP プロトコル

パフォーマンスに大きな影響を与える「HTTP プロトコル」属性は、「DNS 検索が有効」だけです。

DNS 検索が有効

この設定は、サーバーにアクセスするクライアントに対する DNS (ドメインネームサービス) 検索を、サーバーが実行するかどうかを指定します。DNS 検索が有効でない場合、あるクライアントが接続したときに、サーバーはそのクライアントの IP アドレスを認識しますが、そのホスト名は認識しません (たとえば、サーバーはクライアントを www.xyz.com としてではなく、198.95.251.30 として認識する)。DNS 検索が有効である場合、サーバーはクライアントの IP アドレスを解決してホスト名を得ますが、このホスト名は、アクセス制御、CGI (Common Gateway Interface) プログラム、エラー報告、アクセスロギングなどの処理で使用されます。

サーバーが 1 日に多数の要求への応答を行う場合には、DNS 検索を無効にすることで、DNS または NIS (Network Information System) サーバーへの負荷を減らしてください。DNS 検索を有効にすると待ち時間が長くなり、システムへの負荷が高まります。したがって、有効にする場合には注意が必要です。

HTTP ファイルキャッシュ

Application Server は、ファイルキャッシュを使用することで静的情報をより高速に提供します。ファイルキャッシュには、HTML ファイル、CSS ファイル、イメージファイル、テキストファイルなどの静的ファイルに関する情報が格納されます。HTTP ファイルキャッシュを有効にすると、静的ファイルを含むアプリケーションのパフォーマンスが改善されます。

管理コンソールでファイルキャッシュの属性を設定するには、「設定」>「config-name」>「HTTP サービス (HTTP ファイルキャッシュ)」を選択します。

最大ファイル数

最大ファイル数は、キャッシュ内のファイル数を決定します。この値が大きすぎると、必要性のほとんどないファイルまでサーバーがキャッシュに書き込むことになり、メモリーの無駄使いになります。この値が小さすぎると、キャッシュ処理の利点が失われます。この属性のさまざまな値を試し、特定のアプリケーションでの最適解を見つけてください。一般に、効果はそれほど大きくありません。

ハッシュ初期サイズ

ハッシュ初期サイズはメモリー使用量と検索時間に影響を与えますが、これによってパフォーマンスに対する測定可能な効果が得られることは、ほとんどありません。

最大有効期間

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

コンテンツの変更頻度が低い Web サイトでは、パフォーマンスを改善するためにこの値を増やしてください。最大有効期間を設定するには、Web ベースの管理コンソールで、HTTP サーバーノードに対する「HTTP ファイルキャッシュ」ページの「最大有効期間」フィールドで値を入力または変更し、「ファイルキャッシュを有効化」チェックボックスを選択します。

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

小/中のファイルサイズとファイルサイズ上限

キャッシュは小ファイル、中ファイル、大ファイルを異なる方法で処理します。中ファイルのコンテンツは、ファイルが仮想メモリー (Unix/Linux プラットフォーム) にマッピングされることにより、キャッシュされます。小ファイルのコンテンツは、ヒープスペースが割り当てられ、ファイルをそのスペース内に読み込むことにより、キャッシュされます。大ファイルのコンテンツはキャッシュされませんが、大ファイルの情報はキャッシュされます。

小ファイルと中ファイルを区別する利点は、小ファイルが多数ある場合に、仮想メモリーで多くのページが消費されるのを防ぐことにあります。このため、「Small File Size Limit」の値は、通常は VM ページサイズよりもやや低い値になります。

ファイル転送

ファイル転送が有効になっていると、サーバーはファイルのコンテンツではなく、ファイルのオープンファイル記述子をファイルキャッシュに書き込みます。また、キャッシュに書き込まれるのはオープンファイル記述子だけなので、通常行われる小、中、および大ファイルの区別は行われなくなります。

デフォルトでは、Windows では「ファイル転送」は有効に、UNIX では無効に設定されています。UNIX の場合、ファイル転送を有効にできるのは、必須のネイティブ OS サポートを含むプラットフォームだけです。それは HP-UX と AIX です。その他の UNIX/Linux プラットフォームではこれを有効にしないでください。

HTTP リスナー設定のチューニング

管理コンソールで HTTP リスナー設定を変更するには、「設定」>「config-name」>「HTTP サービス」>「HTTP リスナー」>「listener-name」を選択します。

ネットワークアドレス

ネットワークインタフェースカード (NIC) が 1 枚だけ装備されたマシンでは、ネットワークアドレスをそのマシンの IP アドレス (デフォルトの 0.0.0.0 ではなく 192.18.80.23 など) に設定してください。0.0.0.0 以外の IP アドレスを指定すると、サーバーが接続ごとに行うシステムコールの数が、1 つだけ少なくなります。実現可能な最高のパフォーマンスが得られるよう、0.0.0.0 以外の IP アドレスを指定してください。サーバーに複数の NIC カードが搭載されている場合には、NIC ごとに異なるリスナーを作成してください。

アクセプタスレッド

「アクセプタスレッド」設定は、1 つの待機ソケット上で常にいくつのスレッドを受け付けモードにしておく必要があるかを指定します。システムの CPU 数に等しいかそれより小さい値にこれを設定するのは、良い方法です。

Application Server では、HTTP リスナー上のアクセプタスレッドが接続を受け付け、それらを接続キューに入れます。次に、セッションスレッドがキューから接続を取り出し、その要求を処理します。サーバーは、要求の終了時に必要に応じてセッションスレッドを追加します。

新しいスレッドの追加ポリシーは、接続キューの状態に基づいています。

Grizzly の設定

Grizzly は Java の NIO テクノロジを利用した HTTP リスナーであり、そのすべてが Java で実装されています。この再利用可能な NIO ベースのフレームワークを使えば、任意の HTTP 関連操作 (HTTP リスナー/コネクタ) だけでなく非 HTTP 操作も行えるため、スケーラビリティーの高い任意のタイプのマルチスレッドサーバーを作成できます。Grizzly HTTP リスナーは Java プラットフォームの NIO Selector クラス群に基づくキープアライブシステムを使用しますが、このクラス群は接続の監視をサポートしており、サービス拒否攻撃を防ぐのに役立ちます。サービス拒否システムは、リソースの枯渇または「氾濫」攻撃を予測できるよう、IP 検証、IP ごとの完了トランザクション数の追跡、アクティブでない接続の検出などに対する基本的なサポートを追加します。これらすべてのサービスが、キープアライブシステムと組み合わせて実行されます。Grizzly コネクタは静的リソース要求と動的リソース要求の両方をサーブレットコンテナに転送し、サーブレットコンテナはコンテナによって提供される専用のサーブレット (org.apache.catalina.servlets.DefaultServlet) を使って静的リソース要求を処理します。

Grizzly の詳細については、http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html の Weblog を参照してください。

Grizzly は、Application Server Enterprise Edition 8.2 に含まれる NSAPI/WebCore の代替として利用可能になっています。Application Server には、Grizzly の設定をサポートするための特殊なプロパティーがいくつか用意されています。Grizzly を有効にするには、次のプロパティーを追加します。

Dcom.sun.enterprise.web.httpservice.ee=false。

Grizzly の実装は現在のところ、Application Server Enterprise Edition の、動的設定以外のすべての機能をサポートしています。

Grizzly の設定を制御するプロパティーは、次のとおりです。

注 –

Grizzly も、Sun Java System Application Server 8.2 のその他のすべての設定と同じく、非同期起動メカニズムを無効にするとパフォーマンスが向上します。これを無効にするには次のプロパティーを使用します。-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

次の表に、Grizzly プロパティーと production web container (PWC) プロパティーとの対応関係を示します。

表 3–3 Grizzly プロパティーと PWC プロパティーとの対応関係

Grizzly のプロパティー名 

デフォルト値 

説明 

本番 Web コンテナの対応する設定 

maxAcceptWorkerThread 

0 

OP_ACCEPT (socket.accept()) の処理に使用されるスレッドの数。 

HTTP リスナーのアクセプタスレッドの数 

selector.timeout 

60000 

Selector.select() でタイムアウトが発生するまでの、ミリ秒単位の時間。 

要求処理タイムアウト 

minWorkerThreads 

5 

すべてのスレッドプールが作成時に使用する最小スレッド数。 

要求処理の初期スレッド数 

fileCache.isEnabled 

false 

ファイルキャッシュが有効かどうかを示します。 

ファイルキャッシュが有効 

fileCache.minEntrySize 

 

小ファイルで可能な最小サイズ。 

小ファイルのサイズ制限 

fileCache.maxEntrySize 

1024 

中ファイルで可能な最大サイズ。 

中ファイルのサイズ制限 

fileCache.maxLargeFileCacheSize 

10485760 

中ファイル用のキャッシュ領域。 

ファイルサイズ (中) 

fileCache.maxSmallFileCacheSize 

 

小ファイル用のキャッシュ領域。 

ファイルサイズ (小) 

fileCache.maxCacheEntries 

 

キャッシュエントリの最大数。 

最大ファイル数 

keepAliveTimeoutInSeconds 

30 

 

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

maxKeepAliveRequests 

250 

 

キープアライブの最大接続数 

InitialRuleCount 

128 

Keep-Alive サブシステムによって作成される KeepAliveRule の初期数。 

 

useNioNonBlocking 

true 

NIO ブロックモードを使用するかどうかを示します。 

 

displayConfiguration 

false 

Grizzly の内部設定を表示するかどうかを示します。 

 

useDirectByteBuffer 

true 

Grizzly バッファーの作成時に ByteBuffer.allocateDirect() を使用するかどうかを示します。 

 

pipelineClass 

com.sun.enterprise.web.connector.grizzly.LinkedListPipeline 

Grizzly がデフォルトで使用するパイプライン (スレッドプールラッパー)。 

 

maxSelectorReadThread 

1 

OP_READ 操作を処理するためのセレクタスレッドの数。 

 

useByteBufferView 

false 

1 つの大きな ByteBuffer を使用し、それを Grizzly バッファー間で分割するかどうかを指定します。 

 

algorithmClassName 

com.sun.enterprise.web.connector.grizzly.algorithms.NoParsingAlgorithm 

ByteBuffer からのバイトの読み取りに使用される、要求バイト解析アルゴリズム。 

 

buffersize 

4096 

Grizzly によって作成される ByteBuffer のサイズ。 

 

factoryTimeout 

30 

ソケット上での読み書き操作が失敗するまでの時間。 

 

maxReadWorkerThread 

0 

ソケットからの要求バイトの読み取りに使用されるスレッドの数。 

 

Version 7 からの移行

既存のインストールを Application Server version 7.x からversion 8 へ移行する場合には、次の表でチューニング可能パラメータのマッピングを確認してください。

表 3–4 チューニング可能設定の、version 7 から version 8 へのマッピング

version 7.x のチューニング可能設定 

version 8.1 のチューニング可能設定 

RqThrottle 

スレッド数 (thread-count) 

RqThrottleMin 

初期スレッド数 (initial-thread-count) 

ConnQueueSize 

キューサイズ (queue-size-in-bytes) 

KeepAliveThreads 

スレッド数 (keep-alive-thread-count) 

KeepAliveTimeout 

タイムアウト (timeout-in-seconds) 

MaxKeepAliveConnections 

最大接続数 (max-connections) 

KeepAliveQueryMeanTime 

keep-alive-query-mean-time 

KeepAliveQueryMaxSleepTime 

keep-alive-query-max-sleep-time 

ListenQ 

スレッド数 (max-pending-count) 

AcceptTimeout 

要求タイムアウト 

HeaderBufferSize 

バッファー長 

ORB の設定

Application Server には、高いパフォーマンスとスケーラビリティーを備えた CORBA ORB (Object Request Broker) が含まれています。ORB は、サーバー上の EJB コンテナの基盤となります。

概要

ORB は主に、次の経路で EJB コンポーネントによって使用されます。

あるサーバーインスタンスが別のサーバーインスタンスの ORB に接続する場合、その最初のインスタンスはクライアント ORB として機能します。SSL over IIOP では、暗号化アルゴリズムの高パフォーマンスなネイティブ実装を備えた、高速で最適化されたトランスポートが使用されます。

EJB のローカルインタフェースでは ORB が使用されない点に注意してください。ローカルインタフェースを使用する場合、引数はすべて参照として渡されるため、オブジェクトをコピーする必要はまったくありません。

クライアントから ORB への接続方法

あるリッチクライアント Java プログラムが新しい initialContext() 呼び出しを実行すると、クライアント側の ORB インスタンスが作成されます。次にこれが、Application Server IIOP ポートへのソケット接続を作成します。このクライアントからの IIOP 要求を処理するためのリーダースレッドが、サーバー ORB 上で起動されます。クライアントコードは initialContext を使って、サーバー上に配備された EJB の検索を行います。サーバー上に配備された EJB へのリモート参照である IOR が、クライアントに返されます。クライアントコードはこのオブジェクト参照を使って、EJB のリモートメソッドを呼び出します。

Bean の InitialContext 検索とメソッドの呼び出しでは、Java の整列化アプリケーション要求データが IIOP メッセージに変換され、そのメッセージが事前に作成されたソケット接続経由でサーバー ORB へと送信されます。するとサーバーは応答を作成し、それを同じ接続経由で送り返します。次に、応答内のそのデータがクライアント ORB によって非整列化され、クライアントコードに戻されて処理されます。リッチクライアントアプリケーションが終了すると、クライアント ORB は停止して接続を閉じます。

ORB の監視

ORB 統計はデフォルトで無効になっています。ORB 統計を収集するには、次の asadmin コマンドを使って監視を有効にします。

set serverInstance.iiop-service.orb.system.monitoringEnabled=true
reconfig serverInstance

接続の統計

ORB の接続に関して収集される統計は、次のとおりです。

ORB 接続の統計を取得するには、次のコマンドを使用します。

asadmin get --monitor
    serverInstance.iiop-service.orb.system.orb-connection.*

スレッドプール

ORB のスレッドプールに関して収集される統計は、次のとおりです。

ORB スレッドプールの統計を取得するには、次のコマンドを使用します。

asadmin get --monitor
    serverInstance.iiop-service.orb.system.orb-thread-pool.*

ORB のチューニング

ORB のパフォーマンスを調整するには、ORB のパラメータと ORB スレッドプールのパラメータを設定します。通常の場合、負荷分散、複数の共有接続、スレッドプール、およびメッセージ分割サイズを活用することで、応答時間を短縮できます。複数の ORB サーバー間でクライアント要求の負荷分散を行い、クライアントとサーバー間での接続数を調整することで、スケーラビリティーを改善できます。

次の表に、チューニング可能な ORB パラメータをまとめます。

表 3–5 チューニング可能な ORB 設定

パス 

ORB モジュール 

サーバー設定 

アプリケーションクライアントからアプリケーションサーバーへの RMI/ IIOP 

通信インフラストラクチャー、スレッドプール 

steady-thread-pool-size、max-thread-pool-size、idle-thread-timeout-in-seconds 

ORB から Application Server への RMI/ IIOP 

通信インフラストラクチャー、スレッドプール 

steady-thread-pool-size、max-thread-pool-size、idle-thread-timeout-in-seconds 

ベンダー ORB からの RMI/ IIOP 

通信インフラストラクチャーの一部、スレッドプール 

steady-thread-pool-size、max-thread-pool-size、idle-thread-timeout-in-seconds 

インプロセス 

スレッドプール 

steady-thread-pool-size、max-thread-pool-size、idle-thread-timeout-in-seconds 

チューニング可能な ORB パラメータ

管理コンソールを使って次の ORB パラメータをチューニングします。

ORB スレッドプールのパラメータ

ORB スレッドプールには、1 つのタスクキューと一連のスレッドが含まれます。タスクまたはジョブはこのタスクキューに挿入されますが、空き状態のスレッドがこのキューからタスクを取り出し、処理を実行します。タスクキューが常に空になるようなスレッドプールサイズを設定しないでください。大規模アプリケーションの場合、最大プールサイズが現在のタスクキューのサイズの 10 倍になるのが普通です。

Application Server は ORB スレッドプールを次の目的で使用します。

したがって、ORB が RMI/ IIOP 経由のリモート呼び出し用として使用されない場合でも、EJB のプールおよびキャッシュのクリーンアップが円滑に進むように、このスレッドプールのサイズを設定してください。

ORB スレッドプールの属性を設定するには、「設定」>「config-name」>「スレッドプール」>「thread-pool-ID」を選択します。ここで、thread-pool-ID は ORB 用に選択されたスレッドプールの ID です。スレッドプールでパフォーマンスに影響を与える属性は、次のとおりです。

特に、最大プールサイズがパフォーマンス上、重要になります。詳細については、「スレッドプールのサイジング」を参照してください。

クライアント ORB のプロパティー

クライアントプログラムを起動するときに、次のプロパティーをコマンド行引数として指定します。そうするには、Java VM の起動時に次の構文を使用します。

-Dproperty=value

クライアント ORB とサーバー ORB 間の接続の制御

クライアントでデフォルトの JDK ORB を使用する場合、クライアント ORB からアプリケーションサーバー ORB への接続が、初期コンテキストが作成されるたびに確立されます。同じプロセスからオープンされる接続のプーリングまたは共有を行うには、クライアント ORB の設定に次のコードを追加します。

-Djava.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory

複数の接続の使用

注 –

Sun Java System Application Server version 8.x では、プロパティー com.sun.appserv.iiop.orbconnections はサポートされていません。

コンテキストファクトリ (com.sun.appserv.naming.S1ASCtxFactory) を使用する場合、プロパティー com.sun.appserv.iiop.orbconnections を使用することで、クライアント ORB からサーバーに対してオープンする接続の数を指定できます。

デフォルト値は 1 です。複数の接続を使用すると、ネットワーク集約型アプリケーションのスループットが改善される可能性があります。クライアント ORB 上でこの設定変更を指定するには、次の jvm オプションを追加します。

-Djava.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory
-Dcom.sun.appserv.iiop.orbconnections=value

負荷分散

クラスタ内の複数のアプリケーションサーバーインスタンス向けに RMI/IIOP を設定する方法については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の第 11 章「RMI-IIOP 負荷分散とフェイルオーバー」を参照してください。

クライアント ORB の負荷分散や接続数を調整する場合、サーバー ORB 上でオープンされる接続の数を考慮してください。小さい接続数から始め、その数を増やしながら何らかのパフォーマンス改善が見られるか監視します。サーバーへの 1 つの接続は、その接続からアクティブに読み取る 1 つの ORB スレッドへと変換されます (これらのスレッドはプールには格納されず、接続の存続期間中に一時的に存在する)。

スレッドプールのサイジング

前述したようにインバウンド接続とアウトバウンド接続の数を確認したあと、スレッドプールのサイズのチューニングを適切に行います。これは、パフォーマンスと応答時間に大きな影響を及ぼす可能性があります。

サイズを計算する際には、同時に処理するクライアント要求の数、マシン上で利用可能なリソース (CPU 数やメモリー容量)、およびクライアント要求処理時に必要とされる応答時間を考慮します。

このサイズを非常に小さい値に設定すると、サーバーが要求を同時に処理する能力に悪影響が及び、その結果として要求がタスクキュー内にとどまる時間が長くなるため、応答時間にも悪影響が及ぶ可能性があります。これに対し、多数のワークスレッドを使って要求を処理させるのも、問題が生じる可能性があります。なぜなら、システムリソースが大量に消費され、並行性が増大するからです。これは、スレッドが EJB コンテナ内の共有構造を取得するまでの時間が長くなることを意味する可能性があり、その結果、応答時間にも悪影響が及ぶ可能性があります。

また、ワークスレッドプールは、プールやキャッシュの削除など、EJB コンテナの整理アクティビティー用としても使用されます。サイズを決定する際には、このアクティビティーのことも考慮する必要があります。ORB ワークスレッドが多すぎるとパフォーマンスに悪影響が及ぶのは、サーバーがそれらすべてのスレッドを維持する必要が生じるからです。アイドルスレッドタイムアウト期間が過ぎると、アイドルスレッドは破棄されます。

IIOP メッセージの検査

Application Server によって渡された IIOP メッセージを調査することが役立つ場合があります。サーバーが IIOP メッセージを server.log ファイルに保存するようにするには、JVM オプション -Dcom.sun.CORBA.ORBDebug=giop を設定します。クライアント ORB 上で同じオプションを使用します。

サーバーログに保存される IIOP メッセージの例を、次に示します。注意: 実際の出力では、各行の先頭に [29/Aug/2002:22:41:43] INFO (27179): CORE3282: stdout のようなタイムスタンプが付きます。

 ++++++++++++++++++++++++++++++
 Message(Thread[ORB Client-side Reader, conn to 192.18.80.118:1050,5,main]):
createFromStream: type is 4 <
 MessageBase(Thread[ORB Client-side Reader, conn to 192.18.80.118:1050,5,main]): 
Message GIOP version: 1.2
 MessageBase(Thread[ORB Client-side Reader, conn to 192.18.80.118:1050,5,main]): 
ORB Max GIOP Version: 1.2
 Message(Thread[ORB Client-side Reader, conn to 192.18.80.118:1050,5,main]): 
createFromStream: message construction complete.
 com.sun.corba.ee.internal.iiop.MessageMediator
(Thread[ORB Client-side Reader, conn to 192.18.80.118:1050,5,main]): Received message:
 ----- Input Buffer -----
 Current index: 0
 Total length : 340
 47 49 4f 50 01 02 00 04 0 0 00 01 48 00 00 00 05 GIOP.......H....
注 –

フラグ -Dcom.sun.CORBA.ORBdebug=giop を指定すると、多数のデバッグメッセージがログ内に生成されます。これは、メッセージが断片化している疑いがある場合にのみ使用します。

このサンプル出力では、createFromStream のタイプが 4 と表示されています。これは、このメッセージがより大きなメッセージのフラグメントであることを意味しています。メッセージの断片化を防ぐには、フラグメントのサイズを増やします。フラグメントのサイズを大きくすると、メッセージがいくつかのフラグメントとしてではなく、1 つの単位として送信されるため、複数メッセージのオーバーヘッドが抑えられ、そうした複数のメッセージを受信側で結合する処理も必要なくなります。

アプリケーションで送信されるメッセージのほとんどが断片化されている場合、フラグメントサイズを増やせばおそらく効率が改善されます。これに対し、いくつかのメッセージだけが断片化されている場合、フラグメントサイズを小さくしたほうがメッセージの書き込みに必要とされるバッファーも小さくなり、より効率的である可能性があります。

Java 直列化による ORB のパフォーマンス改善

ネットワーク上でのトランスポート用データで、標準の CDR (Common Data Representation) の代わりに Java 直列化を使用すると、ORB のパフォーマンスを改善できます。この機能は、Java Serialization over GIOP (General Inter-ORB Protocol) または JSG と呼ばれます。

場合によっては、JSG は CDR よりもパフォーマンスやスループットが良くなる可能性があります。そのパフォーマンスの差異は、アプリケーションによって大きく異なります。クライアントとサーバー間で少量のデータが転送されるようなリモートオブジェクトを含むアプリケーションで JSG を使用すれば、パフォーマンスが改善される可能性が非常に高くなります。

ProcedureJava 直列化を有効にする

JSG を使用するすべてのサーバー上で、このプロパティーを設定する必要があります。

  1. ツリーコンポーネントで、「設定」ノードを開きます。

  2. 目的のノードを展開します。

  3. 「JVM 設定」ノードを選択します。

  4. 「JVM 設定」ページで「JVM オプション」タブを選択します。

  5. 「JVM オプションを追加」をクリックし、次の値を入力します。

    -Dcom.sun.CORBA.encoding.ORBEnableJavaSerialization=true

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

  7. Application Server を再起動します。

アプリケーションクライアントでの JSG の使用

アプリケーションがスタンドアロンの非 Web クライアント (アプリケーションクライアント) を使用する場合、JSG を使用するには、クライアントアプリケーションのシステムプロパティーも設定する必要があります。これを行うには通常、クライアントアプリケーションの起動に使用される Java コマンド行に、このプロパティーを追加します。次に例を示します。

java -Dcom.sun.CORBA.encoding.ORBEnableJavaSerialization=true
 -Dorg.omg.CORBA.ORBInitialHost=gollum
 -Dorg.omg.CORBA.ORBInitialPort=35309
MyClientProgram

スレッドプールの設定

管理コンソールを使えば、スレッドプール設定の監視とチューニングをどちらも行えます。管理コンソールで監視を設定するには、ページ「設定」>「config-name」>「監視」を開きます。管理コンソールで監視情報を表示するには、ページ「スタンドアロンインスタンス」>「instance-name (監視)」を開きます。

スレッドプールのチューニング (Unix /Linux のみ)

管理コンソールでスレッドプールの設定を行うには、「設定」>「config-name」>「スレッドプール」を選択します。

Unix/Linux のスレッドは常に、ユーザーによってスケジュールされる代わりにオペレーティングシステム (OS) によってスケジュールされるため、Unix/Linux ユーザーはネイティブスレッドプールを使用する必要がありません。したがって、Unix/Linux ユーザーインタフェースではこのオプションは提供されていません。ただし、必要であれば、OS によってスケジュールされるスレッドプールの編集や新しいスレッドプールの追加を、管理コンソールで行うことは可能です。

リソース

JDBC 接続プールの設定

データベース集約型アプリケーションで最適なパフォーマンスが得られるよう、Application Server によって管理される JDBC 接続プールの調整を行います。これらの接続プールは生存中のデータベース接続を多数維持しますが、そうした接続を再利用すれば、データベース接続のオープン/クローズによるオーバーヘッドの低減が図れます。この節では、JDBC 接続プールをチューニングしてパフォーマンスを改善する方法について説明します。

J2EE アプリケーションは、JDBC 接続プールによって維持されている接続を、JDBC リソース経由で取得します。複数の JDBC リソースが同一の JDBC 接続プールを参照してもかまいません。そのような場合、1 つの物理的な接続プールがすべてのリソースで共有されます。

JDBC 接続プールの監視

JDBC 接続プールの統計収集は、デフォルトで有効になっています。監視される属性は次のとおりです。

統計を取得するには、次のコマンドを使用します。

asadmin get --monitor=true 
serverInstance.resources.jdbc-connection-pool.*asadmin get 
--monitor=true serverInstance.resources.jdbc-connection-pool. poolName.* *

JDBC 接続プールのチューニング

管理コンソールで JDBC 接続プールの属性を設定するには、「リソース」>「JDBC」>「接続プール」>「PoolName」を選択します。パフォーマンスに影響を与える属性は、次のとおりです。

プールサイズの設定

接続プールのサイズを制御する設定は、次のとおりです。

初期および最小プールサイズ

作成時のプールのサイズおよびその最小許容サイズ。

最大プールサイズ

プールのサイズの上限。

プールサイズ変更量

アイドルタイムアウト発生時に削除される接続の数。タイムアウトよりも長い間アイドル状態になっていた接続が、削除対象の候補となります。プールサイズが初期および最小プールサイズに達すると、接続の削除が停止します。

次の表に、接続プールのサイジング時に考慮すべき利点と欠点をまとめます。

表 3–6 接続プールのサイジング

接続プール 

利点 

欠点 

小さい接続プール 

接続テーブルへのアクセスがより高速になります。 

要求の処理に必要な接続を十分に確保できない可能性があります。 

要求がキュー内で費やす時間がより長くなります。 

大きい接続プール 

要求を処理するための接続がより多く存在します。 

要求がキュー内で費やす時間が、より少なくなるか、まったくなくなります 

接続テーブルへのアクセスがより低速になります。 

タイムアウトの設定

タイムアウト設定には次の 2 つがあります。

遮断レベルの設定

データベースサーバー上での接続プールのトランザクション遮断レベルを制御する設定には、次の 2 つがあります。

トランザクション遮断レベルを指定しないようにしてください。それが不可能な場合は、「遮断レベルを保証」を false に設定することを検討し、アプリケーションがプログラミングによって接続の遮断レベルを変更しないことを確認してください。

遮断レベルを指定する必要がある場合には、できるだけ高いパフォーマンスが得られるレベルを指定してください。次に、遮断レベルの一覧をパフォーマンスの高い順に示します。

  1. READ_UNCOMMITTED

  2. READ_COMMITTED

  3. REPEATABLE_READ

  4. SERIALIZABLE

最高のパフォーマンスが得られ、かつ並行性や整合性に関するアプリケーションのニーズも満たせるような遮断レベルを選択してください。

接続検証の設定

次の各設定によって、プールが接続検証を実行するかどうか、およびその実行方法が決まります。

接続検証

Required がチェックされている場合、プールは、接続の検証 (接続が使用可能かどうかのチェック) を行なったあとで、その接続をアプリケーションに渡します。

可能であれば、デフォルト値の false のままにしてください。接続検証を要求すると、プールが接続を返すたびにサーバーが検証アルゴリズムを適用しなければいけなくなるため、getConnection() の待ち時間のオーバーヘッドが増大します。データベースの接続が信頼できる場合には、検証を省略できます。

検証方法

実行する接続検証のタイプ。必ず次のどれかになります。

  • auto-commit: 接続上で自動コミットの実行を試みます。

  • metadata: 接続からのメタデータの取得を試みます。

  • table (指定されたテーブルに対してクエリーを実行する): 「表名」も設定する必要があります。JDBC ドライバが setAutoCommit() や getMetaData() への呼び出しをキャッシュに書き込む場合、この方法を使用しなければいけない可能性があります。

表名

検証方法が「table」の場合にクエリー対象となる表の名前。 

「すべての障害ですべての接続を閉じる」チェックボックス

ある単一の検証チェックが失敗した場合にプール内のすべての接続を閉じるかどうか。デフォルトはチェックなしです。失敗した接続を再確立する試行は、1 回行われます。

コネクタ接続プールの設定

パフォーマンスの観点から見ると、コネクタ接続プールは JDBC 接続プールに似ています。1 つ前の節である、「JDBC 接続プールのチューニング」で説明した推奨事項に従ってください。

トランザクションサポート

各コネクタ接続プールで指定されたデフォルトのトランザクションサポートを上書きすることで、パフォーマンスを改善できる可能性があります。

たとえば、あるエンタープライズ情報システム (EIS) の接続ファクトリが、グローバルトランザクションよりも高いパフォーマンスを示すローカルトランザクションをサポートしているような場合を考えます。この EIS からのリソースを別のリソースマネージャーからのリソースと混在させる必要がある場合、デフォルト動作では XA トランザクションの使用が強制されるため、パフォーマンスが低下します。しかしながら、この EIS のコネクタ接続プールが LocalTransaction トランザクションサポートを使用するように変更し、前述した最終エージェント最適化機能を活用すれば、より高いパフォーマンスを示す EIS の LocalTransaction 実装を活用できます。LAO の詳細については、「JDBC リソースを 1 フェーズコミットリソースとして設定する」を参照してください

管理コンソールでは、「リソース」>「コネクタ」>「コネクタ接続プール」で新しいコネクタ接続プールを作成したりコネクタ接続プールを編集したりするときに、トランザクションサポートを指定します。

また、asadmin を使ってトランザクションサポートを設定することもできます。たとえば、次の asadmin コマンドを使えば、トランザクションサポートが「LOCAL」のコネクタ接続プール「TESTPOOL」を作成できます。

asadmin> create-connector-connection-pool --raname jdbcra 
--connectiondefinition javax.sql.DataSource 
-transactionsupport LocalTransaction 
TESTPOOL