IBM WebSphere Application Server アドバンスド版
チューニング・ガイド
IBM WebSphere Application Server アドバンスド版チューニング・ガイド |
|
パフォーマンス・チューナー・ウィザード
動的フラグメント・キャッシング
これを管理コンソールから呼び出すには、「コンソール (Console)」 > 「Wizards」 > 「Performance Tuner」と選択してください。
詳細は、インフォセンターの項目 6.6.21 を参照してください。
動的フラグメント・キャッシングは、動的なサーブレットと JSP ファイルの出力をキャッシュに入れる機能で、アプリケーションのパフォーマンスを劇的に向上させる技術です。このキャッシュは、アプリケーション・サーバーの JVM 内で機能し、サーブレットの service() メソッドへの呼び出しを代行受信して、サーブレットを再実行する代わりにキャッシュから起動できるかどうか検査します。 J2EE アプリケーションは読み取り書き込み率が高く、データの新しさに関する遅延の許容度が低いので、フラグメント・キャッシングを使用すると、サーバーの応答時間、スループット、およびスケーラビリティーが劇的に改善される可能性があります。
サーブレットが実行されると (キャッシュに入れられる出力を生成する)、その出力が入ったキャッシュ項目が生成されます。実行の副次作用 (つまり、他のサーブレットまたは JSP ファイルの呼び出し) と、タイムアウトや項目の優先順位情報などの項目に関するメタデータも生成されます。固有な項目は、サーブレットの呼び出しごとに HttpServletRequest オブジェクトから生成される ID ストリングによって区別されます。このため、キャッシュに入れられるサーブレットは、URI がサーブレットまたはセッション情報の呼び出しに使用した要求パラメーターによって決まります。JSP は WebSphere Application Server によってコンパイルされてサーブレットになるので、JSP とサーブレットは交換して使用できます (XML ファイル内で要素を宣言するときを除く)。
この設定を行うには、次のようにします。
詳細は、インフォセンターの項目 4.5: 動的フラグメント・キャッシング を参照してください。
| 症状 | 追加情報 |
| スループットおよび応答時間が望ましくない。 | プロセッサー速度 |
|
AIX: メモリーの割り振りエラー Solaris: オープン・ファイルが多すぎる | AIX ファイル記述子 (ulimit) または Solaris ファイル記述子 (ulimit) |
| Solaris: サーバーがピーク期間中に停止し、応答には何分も掛かり、システム処理のアクティビティー全体でプロセッサーの使用率が高いままである。さらに、netstat を使用すると、CLOSE_WAIT または FIN_WAIT_2 状態にあり、ポート 80 に対してオープンになっているソケットが幾つかあることが示される。 | Solaris tcp_close_wait_interval/tcp_time_wait_interval および Solaris tcp_fin_wait_2_flush_interval |
| Windows NT/2000: netstat により、TIME_WAIT 状態にあるソケットが多すぎることが表示される。 | Windows NT/2000 TcpTimedWaitDelay |
| HP-UX 11: スループットが望ましくなく、アプリケーション・サーバーの優先度が調整されていない。 | WebSphere Application Server プロセスのオペレーティング・システム優先度の調整 |
| 負荷がある場合に、クライアントの要求がタイムアウトになるかまたはリジェクトされるため、Web サーバーに到着しない。 |
HP-UX 11 については、HP-UX 11 tcp_conn_request_max を参照 IIS Windows NT/2000 については、ListenBackLog パラメーター を参照 NT 版の IBM HTTP Server については、ListenBackLog を参照 |
| Windows NT/2000: 他のベンダーのアプリケーション・サーバーをインストールした後に、WebSphere Application Server のパフォーマンスが低下した。 | IIS 許可プロパティー |
| リソース・アナライザーの最大パーセント・メトリックに、Web コンテナーのスレッド・プールが小さすぎることが示されている。 | Web コンテナーの最大 ThreadsMax 接続数 |
| netstat により、ポート 9080 に対し TIME_WAIT 状態のソケットが多すぎることが示される。 | Web コンテナー・トランスポートのキープアライブの最大数 |
| ページングが原因で、ディスクの入出力回数が多すぎる。 | ヒープ・サイズの設定値 |
| リソース・アナライザーのデータ・ソース接続プールの最大パーセント・メトリックに、プールのサイズが大きすぎることが示されている。 | WebSphere データ・ソース接続プールのサイズ |
| リソース・アナライザーの準備済みステートメント・キャッシュ廃棄メトリックに、データ・ソースの準備済みステートメント・キャッシュのサイズが小さすぎることが示されている。 | 準備済みステートメント・キャッシュのサイズ |
| DB2 書き込みログ・レコードが原因で、ディスクの入出力回数が多すぎる。 | DB2 MinCommit |
| リソース・アナライザーの最大パーセント・メトリックに、オブジェクト・リクエスト・ブローカーのスレッド・プールが小さすぎることが示されている。 | キューイングと Enterprise Bean |
| リソース・アナライザーの Java 仮想マシン・プロファイラー・インターフェース (JVMPI) に、ガーベッジ・コレクションに費やしている時間が多すぎるときに、オブジェクトを過剰に使用していることが示されている。 | オブジェクトの過剰使用の検出 |
| リソース・アナライザーの最大パーセント・メトリックに、メモリー・リークが起こり、 Java がメモリー不足例外を表示していることが示されている。 | メモリー・リークの検出 |
| スループット、応答時間、およびスケーラビリティーが望ましくない。 | アプリケーションが許可する場合、 動的フラグメント・キャッシングを活用する |
チューニングに利用可能なプロシージャーを使用することで、WebSphere Application Server に対し、広範囲に渡りパフォーマンスを改善することができます。この「チューニング・ガイド」では、一般的な推奨事項および特定のチューニング方法論を説明することによって、チューニングの方法を解説します。この「チューニング・ガイド」では、さらに、パフォーマンス・チューニングを拡張するさまざまな要因と変数に関するヒントも提供します。
「チューニング・ガイド」を説明文中の例示およびリソースと共に活用して、チューニングの経験を積んでください。チューニングは、進行する学習プロセスです。このガイドで紹介されている結果は、実際の結果とは異なる場合があります。
便宜のために、他製品のパラメーターを設定するための手順がいくつか説明されています。他製品は変更される場合があるので、これらの手順は参考用と考えてください。
チューニングには、アプリケーション・チューニングとパラメーター・チューニングの 2 つのタイプがあります。
アプリケーション・チューニングによって最大のチューニング効果が得られる場合もありますが、この資料では主に、個々のパフォーマンス・パラメーターと、パラメーター間の相互作用について説明します。
ホワイト・ペーパー WebSphere Application Server Development Best Practices for Performance and Scalability は、アプリケーション・チューニングを扱っています。ここでは、サーブレット、 JavaServer Pages (JSP) ファイル、JDBC (Java Database Connectivity) を含む Web アプリケーション、および Enterprise Bean コンポーネントを含むエンタープライズ・アプリケーションの両方について、開発上の推奨事項を説明しています。
次の表は、各種のハイパフォーマンス向上チューニング・パラメーターの一覧です。
以下のパラメーターを使用すると、機能の問題を防ぐのに役立ちます。
| ListenBackLog パラメーター: IIS を使用して Windows NT/2000 が稼働中で、クライアントの負荷が高い場合に適用される |
| トランスポート・タイプ: Solaris 上の INET ソケットを使用する (WebSphere Application Server の場合のデフォルト) |
| DB2 への接続数: デフォルトの DB2 設定値以上の接続を設定する場合 |
| 最大数より多いの数のスレッド割り振りの許可 が選択されており、割り振られたスレッドの数が多すぎるために、システムが過負荷になっている |
| DB2 Linux 版に TCP ソケットを使用: ローカル・データベースの場合 |
| WebSphere データ・ソース接続プールのサイズ: エンティティー EJB でトランザクション処理するのに必要な追加の接続を処理し、デッドロックを回避するための接続が十分にあることを確認する |
WebSphere Application Server には、一連の相互に関連のあるコンポーネントがあります。それらは、ユーザーのエンドツーエンド e-business アプリケーションのカスタム要件をサポートするように、調整する必要があります。これらの調整によって、システムは、安定を維持しながら最大のスループットを達成できるようになります。
WebSphere Application Server は、キューイング・ネットワークを確立します。これは、アプリケーション・サービス・プラットフォームのさまざまなコンポーネントを表す、相互接続キューのネットワークです。これらのキューには、ネットワーク、Web サーバー、Web コンテナー、EJB コンテナー、データ・ソースが含まれ、カスタム・バックエンド・システムへの接続マネージャーが含まれる場合もあります。これらのリソースのそれぞれが、そのリソースを使用するために待機している要求のキューです。
WebSphere のキューは、負荷に依存するリソースです。つまり、要求の平均サービス時間は、同時クライアントの数に依存します。
キューイング・ネットワークを構成するほとんどのキューは、クローズ・キューです。オープン・キューとは対照的に、クローズ・キューはキュー内に存在する要求の最大数に限度を設定します。
クローズ・キューによって、システム・リソースが厳重に管理できるようになります。たとえば、Web コンテナーの最大接続数を設定して、 Web コンテナー・キューのサイズを制御します。 Web コンテナー内で実行中のサーブレットが、各要求で平均 10MB のオブジェクトを作成する場合、最大接続数の値を 100 に設定すると、Web コンテナーによって消費されるメモリーは 1GB に制限されます。
クローズ・キュー内では、要求はアクティブか待ちのどちらかの状態になります。アクティブ要求は、作業中か、またはダウンストリーム・キューからの応答待ちのどちらかです。たとえば、Web サーバー内のアクティブ要求は、作業中 (静的 HTML の検索など) か、または Web コンテナー内で要求の完了待ちのどちらかです。待ち状態では、要求はアクティブになるのを待っています。 要求は、アクティブ要求の 1 つがキューから出るまで、待ち状態のままです。
WebSphere Application Server によってサポートされている Web サーバーはすべてクローズ・キューであり、WebSphere Application Server データ・ソースも同様です。 Web コンテナーは、オープン・キューまたはクローズ・キューのどちらにも構成できます。通常は、クローズ・キューにすることをお勧めします。 EJB コンテナーはオープン・キューです。プール内に使用可能なスレッドがない場合は、要求の期間に新規スレッドが作成されます。
Enterprise Bean がサーブレットによって呼び出されている場合、 Web コンテナーは EJB コンテナーへの合計同時要求数を制限します。これは、Web コンテナーにも限度があるためです。 このことは、Enterprise Bean をサーブレットの実行スレッドから呼び出している場合だけ当てはまります。 ユーザーがスレッドを作成して、EJB コンテナーに大量の要求を出すことを防ぐ手段はありません。これは、サーブレットが自身の作業スレッドを作成することがよくない理由の 1 つです。
以下で、さまざまなキュー設定値を概説します。
以下のセクションでは、WebSphere Application Server キューを構成するための方法論について概説します。リソースの移動 (たとえば、データベース・サーバーの他のマシンへの移動など)、またはより高速でメモリーもより多い CPU などの、より強力なリソースの提供によって、システムのダイナミックスは変化する場合があるので、チューニング・パラメーターも変化する場合があります。そのため、実稼動環境の特定の構成に合わせて、チューニング・パラメーターを調整してください。
チューニングの最初の規則は、WebSphere Application Server のキューの要求数を最小化することです。 一般に、要求がネットワーク内 (Web サーバーの前) で待つことは、WebSphere Application Server 内で待つよりも良いことです。この構成では、処理準備済みの要求だけが、キューイング・ネットワーク内にあることになります。 この構成を実現するには、最もアップストリームにある (クライアントに近い) キューをやや大きく指定し、ダウンストリームのキュー (クライアントから遠い) は徐々に小さくなるように指定します。
このキューイング・ネットワーク内のキューは、作業がダウンストリームに流れるにつれて小さくなります。 Web サーバーに 200 のクライアントが到着すると、125 の要求がネットワーク内でキューに入ったままになります。これは、Web サーバーが 75 の同時クライアントを処理するように設定されているためです。 75 の要求が Web サーバーから Web コンテナーに渡されるので、 25 の要求は Web サーバー内のキューに入ったままになり、残りの 50 は Web コンテナーによって処理されます。このプロセスは、25 ユーザーが最終宛先であるデータベース・サーバーに到着するまで、データ・ソース内を進行していきます。アップストリームの各ポイントに、コンポーネントに入るのを待っている作業があるので、作業の到着を待つ必要があるコンポーネントはこのシステムにありません。要求の大部分は、WebSphere Application Server の外部のネットワーク内で待機しています。これにより、どのコンポーネントも過負荷にならないため、安定性が増します。 IBM の Network Dispatcher などのルーティング・ソフトウェアを使用すれば、待機中のユーザーを WebSphere Application Server クラスター内の他のサーバーに誘導できます。
実動アプリケーションのすべてのフロー (たとえば、意味のあるコード・パスすべて) に相当するテスト・ケースまたは実動アプリケーションをそのまま使用し、稼働実験を行って、システムの能力が最大化される飽和点を見つけます。これらのテストは、アプリケーションからほとんどのボトルネックが除去された後で実行してください。これらのテストの一般的なゴールは、CPU を活用して 100% に近い使用率にすることです。
初期のベースラインとして、キューを大きくして実験を開始してください。 これにより、システム全体で最大の並行処理能力を発揮できます。たとえば、キューイング・ネットワーク (Web サーバー、 Web コンテナー、およびデータ・ソース) 内の各サーバーで、キュー・サイズを 100 として、最初の実験を開始します。
次に、同時ユーザーの負荷を増やしながら、一連の実験を開始し、スループット・カーブを作図します。たとえば、1 ユーザー、2 ユーザー、5 ユーザー、10、25、50、100、150 および 200 ユーザーで、実験を行います。 1 回ごとに、スループット (要求数 / 秒) と応答時間 (秒数 / 要求) を記録します。
基礎実験から得られるカーブは、以下に示す典型的なスループット・カーブと共通点があるはずです。
WebSphere Application Server のスループットは、システム全体に存在する同時要求の数の関数です。 セクション A は軽負荷ゾーンです。このゾーンは、同時ユーザー要求の数が増えるにつれて、スループットが要求の数と共にほとんど直線的に増えることを示しています。 これは、負荷が軽い場合、同時要求が WebSphere Application Server のシステム・キュー内ではほとんど輻輳 (ふくそう) 状態にならないことを示しています。WebSphere Application Server システム内のボトルネックによって、ある点からは、輻輳状態が徐々に増え、スループットは、最大スループット値を表す飽和点に達するまではるかに遅い速度で増えます。最も管理しやすいタイプのボトルネックは、WebSphere Application Server マシンの CPU が飽和点に達したときに発生するものです。 このボトルネックが望ましい理由は、CPU を追加または強化することによって CPU のボトルネックを改善できることです。
重負荷ゾーン、つまりセクション B では、同時クライアントの負荷は増えますが、スループットは比較的変化しません。ただし、応答時間はユーザーの負荷に比例して増えます。つまり、重負荷ゾーンでユーザーの負荷を倍にすると、応答時間も倍になります。 セクション C、バックル・ゾーンに達すると、システム・コンポーネントの 1 つが使い尽くされてしまいます。 この点から、スループットの低下が始まります。たとえば、Web サーバーでのネットワーク接続がネットワーク・アダプターの限度を超えたり、オペレーティング・システムがファイルを処理するための限度を超えたりすると、システムはバックル・ゾーンに入ります。
システム CPU の使用率が 100% 近くになって飽和点に達した場合は、次のステップに進んでください。 CPU の使用率が 100% 近くになっていない場合は、アプリケーションによってボトルネックが悪化している可能性があります。たとえば、ガーベッジ・コレクションのボトルネックを過度に起こす Java オブジェクトを、アプリケーションが作成していることがあります。
アプリケーションのボトルネックを管理する方法は 2 つあります。ボトルネックを除去するか、ボトルネックのクローンを作成することです。ボトルネックを管理する最良の方法は、それを除去することです。Java ベース・アプリケーション・プロファイラーを使用して、全体的なオブジェクト使用率を調査してください。 Performance Trace Data Visualizer(PTDV)、JProbe、Jinsight などのプロファイラーを使用できます。
スループットの飽和点の同時ユーザーの数は、アプリケーションの最大並行数を表します。 たとえば、アプリケーションがユーザー数 50 で WebSphere Application Server の飽和点に達した場合は、ユーザー数 48 がスループットと応答時間の最良の組み合わせになります。この値は、最大アプリケーション並行数の値と呼ばれます。 最大アプリケーション並行数は、ユーザーの WebSphere Application Server システム・キューを調整するための、基本として使用する値になります。 ユーザーの大部分がネットワーク内で待機していることが望ましいので、クライアントからダウンストリームに進むにつれて、キューのサイズを減らすことを覚えておいてください。たとえば、最大アプリケーション並行数の値が 48 の場合、システム・キューの値は、Web サーバー 75、Web コンテナー 50、データ・ソース 45 から始めます。 最適な設定値を見つけるために、上記の値を少し高くしたり、低くしたり調整して追加の実験を続けてください。
リソース・アナライザーを使用して、サーブレット・エンジンのスレッド・プールの並行アクティブ・スレッド数を測定基準として、並行ユーザー数を判別できます。
パフォーマンスの実験では、Web コンテナーのトランスポートのキープアライブの最大数が Web コンテナーのスレッドの最大数と一致するように調整した場合に、スループットが 10 〜 15% 増えました。
通常は、わずかな要求だけが 1 つのキューを通過して、次のダウンストリームに入ります。多数の静的ページがあるサイトでは、要求の多くが Web サーバー・サイドで処理され、Web コンテナーには渡されません。このような環境では、Web サーバーのキューを Web コンテナーのキューよりもかなり大きくすることができます。 前のセクションでは、Web サーバー・キューを 75 に設定しましたが、この値は最大アプリケーション並行数に近い値ではありませんでした。 それぞれのコンポーネントの実行時間が異なる場合にも、同様な調整が必要です。
たとえば、アプリケーションの実行時間の 90% が複雑なサーブレットに費やされ、10% だけが短い時間の JDBC 照会を行う場合、任意の時点でデータベース接続を使用するサーブレットは平均 10 % なので、データベース接続キューは Web コンテナーのキューよりかなり小さく設定できます。 逆に、サーブレット実行時間の多くがデータベースへの複雑な照会に費やされている場合は、Web コンテナーとデータ・ソースの両方でキューの値を増やすことを検討してください。 CPU もメモリーも飽和状態になっていないことを確認するために、常に WebSphere Application Server とデータベース・サーバーの両方で、CPU とメモリーの使用率をモニターしてください。
Enterprise Bean に対するメソッド呼び出しは、メソッド呼び出しを実行しているクライアントがリモート側にある、たとえば、EJB クライアントが Enterprise Bean とは分離した Java 仮想マシン (別のアドレス・スペース) 内で稼働している場合にだけ、キューに入れられます。 これに対し、EJB クライアント (サーブレットまたは別の Enterprise Bean ) が同一の JVM にインストールされている場合、EJB メソッドは EJB クライアントと同一の実行スレッド上で稼働し、キューイングは行われません。
リモート Enterprise Bean は、RMI/IIOP プロトコルを使用して通信します。 RMI/IIOP によって開始されたメソッド呼び出しは、サーバー・サイドの ORB によって処理されます。スレッド・プールは、着信要求のキューの役割を果たします。ただし、リモート・メソッド要求が発行されて、スレッド・プール内にもう使用可能なスレッドがない場合、新しいスレッドが作成されます。 メソッド要求が完了した後で、そのスレッドは破棄されます。したがって、ORB がリモート・メソッド要求を処理するために使用された場合、そのスレッドの使用に制限がないため、EJB コンテナーはオープン・キューです。 次の図は、Enterprise Bean の 2 つのキューイング・オプションを表しています。
スレッド・プールを構成する際は、EJB クライアントの呼び出しパターンを理解することが重要です。サーブレットがリモート Enterprise Bean を呼び出す回数が少なく、各メソッド呼び出しが比較的高速の場合、ORB スレッド・プール内のスレッド数を、Web コンテナーのスレッド・プールのサイズの値よりも小さな値に設定することを検討してください。
リソース・アナライザーには、構成されるスレッドすべてが使用中である時間を判別するために使用する、最大パーセントと呼ばれるメトリックが示されます。この値が常に 2 桁の場合、ORB がボトルネックになっている可能性があり、スレッドの数は増えるはずです。
ORB スレッド・プール値を増やす必要がある度合いは、 Enterprise Bean を呼び出す同時サーブレット (つまり、クライアント) の数と、各メソッド呼び出しの存続期間の関数です。 メソッド呼び出しが長い場合、リモート・メソッド呼び出しのインターリービングが小さいので、ORB スレッド・プール・サイズを Web コンテナーのサイズと等しくすることを考えてください。サーブレットが ORB に対して短期間または高速の呼び出しだけを行う場合は、ORB スレッド・プールを小さくすることができます。 サーブレットが複数あると、同一の ORB スレッドを再利用できる可能性があります。この場合、ORB スレッド・プールを小さくでき、場合によっては Web コンテナーのスレッド・プール・サイズ設定値の半分にすることもできます。 ORB 内でのアプリケーションの実行時間が長い場合は、 Web コンテナーと ORB がより対等の関係になるように構成します。
アプリケーション・サーバーのクローンを作成する機能は、高度に拡張性のある実動環境を構成するために貴重な強みになります。このことは特に、対称型マルチプロセッシング (SMP) サーバーの CPU のフル活用を妨げるボトルネックがあるアプリケーションには重要です。 クラスター化構成の WebSphere Application Server のシステム・キューを調整する場合は、サーバーをクラスターに追加すると、サーバーのダウンストリームの負荷は 2 倍になることに注意してください。
2 つの Web コンテナー・クローンが、Web サーバーとデータ・ソースの間に配置されています。Web サーバー、サーブレット・エンジン、およびデータ・ソース (データベースではない) は、すべて単一の SMP サーバー上で稼働していると想定されます。 これらの制約がある場合、キューについて次のことを考慮する必要があります。
SSL 接続が確立されると、SSL ハンドシェークが起こります。 接続が確立した後に、SSL は読み取り / 書き取りそれぞれに対して、バルク暗号化と暗号化解除を実行します。 SSL ハンドシェークのパフォーマンス・コストは、バルク暗号化と暗号化解除よりもはるかに大きくなります。
SSL パフォーマンスを拡張するには、個々の SSL 接続数およびハンドシェーク数を減少させる必要があります。
接続数を減少させることにより、単純な TCP 接続を通じてのセキュアでない通信と同様に、SSL 接続を通じてのセキュアな通信のパフォーマンスも向上します。個々の SSL 接続を減少させる 1 つの方法は、HTTP 1.1. をサポートするブラウザーを使用することです。ユーザーが HTTP 1.1. にアップグレードできない場合には、個々の SSL 接続を減少させることは不可能である場合があります。
2 つの WebSphere Application Server コンポーネント間の接続数 (TCP と SSL の両方) を減少させることの方がよく行われます。 Web サーバーのプラグインがアプリケーション・サーバーに対して新規接続を繰り返し再オープンしないように、アプリケーション・サーバーの HTTP トランスポートが構成されていることを確認する際に、以下のガイドラインが役に立ちます。
WebSphere Application Server が現在サポートとしているハードウェア・アクセラレーターを使用すると、SSL ハンドシェークのパフォーマンスが向上するだけであり、バルク暗号化 / 暗号化解除のパフォーマンスは向上しません。 Web サーバーの接続は短いので、アクセラレーターは通常、Web サーバーに対してだけ利点があります。WebSphere Application Server 内の他のすべての SSL 接続は長いため、これらの接続は、SSL ハンドシェークだけを加速させるハードウェア装置からは恩恵を受けません。
暗号スイートのパフォーマンスは、ソフトウェアとハードウェアで異なります。 暗号スイートがソフトウェアでのパフォーマンスが良いからといって、ハードウェアでのパフォーマンスが良いとは限りません。 ハードウェアには、通常、非効率的なアルゴリズム (DES と 3DES など) もありますが、専門のハードウェアを使用すると、これらと同じアルゴリズムを効率良くインプリメンテーションできます。
バルク暗号化 / 暗号化解除のパフォーマンスは、個々の SSL 接続に使用する暗号スイートに影響されます。データを計算するテスト用のソフトウェアは、クライアントとサーバーのソフトウェアに IBM JSSE を使用し、暗号のハードウェアは使用しませんでした。テストには、接続を確立した時間は含まれませんでしたが、確立した接続を使用してデータを送信する時間は含まれました。 そのため、このデータからは、さまざまな暗号スイートにおいて接続が長期に渡るときの SSL の相対的なパフォーマンスが分かります。
接続を確立する前に、クライアントは各テスト・ケース用に単一の暗号スイートを使用可能にしました。接続を確立した後、クライアントは、クライアントがサーバーに整数を書き込むために費やした時間、およびサーバーがクライアントに特定数のバイトを書き込み返す時間を計りました。データ量を変えたために、暗号スイートの相対的パフォーマンスにごくわずかな影響がありました。以下のグラフは、各暗号スイートのパフォーマンスを表しています。
このデータの分析によって、以下が分かりました。
チェックリストには以下の設定があります。
コミット・オプション A は、トランザクションの範囲外のデータベース・データをキャッシュすることによって、Enterprise Bean のパフォーマンスを最大に引き出すことができます。 通常、コミット・オプション A は、EJB コンテナーが特定のデータベースに排他的アクセスを行う場合にだけ、適用できます。これ以外の場合、データ保全性は危険にさらされます。 コミット・オプション B は、エンティティー EJB オブジェクトのインスタンスをより積極的にキャッシュするので、コミット・オプション C よりもパフォーマンスが向上しますが、メモリーをより多く使用することにもなります。 コミット・オプション C は、エンティティー EJB の構成に、実際に最も頻繁に使用されます。
「活動化 (Activate At)」および「ロード (Load At)」プロパティーの設定値は、使用するコミット・オプションを決定します。
分離レベルは、パフォーマンスにおいても大きな役割を果たします。 分離レベルが高い場合、データ・アクセスの並行性を減らす間に行のロックおよびデータベースのオーバーヘッドを増やすことによって、パフォーマンスが減少します。さまざまなデータベースの動作は、分離の設定値によって異なります。 通常 DB2 データベースでは、「反復可能読み取り (Repeatable Read)」が適切な設定値です。「読み取りコミット (Read Committed)」は、通常、Oracle に使用します。Oracle は、「反復可能読み取り (Repeatable Read)」はサポートせず、この設定値を、シリアライズ可能な分離の最高レベルに変換します。
分離レベルは、Bean またはメソッドのレベルで設定することができます。 そのため、さまざまなメソッドに対し、異なる分離の設定値を構成することができます。 これは、分離レベルを他のメソッドより高くする必要があるメソッドが存在する場合に便利であり、保全性の要件を維持しながら最高のパフォーマンスを達成するために使用できます。 しかし、単一の Enterprise Bean トランザクション内のメソッド呼び出し間で、分離を変更することはできません。 この場合、ランタイム例外がスローされます。
反復可能読み取り
このレベルは、ダーティー読み取り、および反復不能読み取りを禁止しますが、ファントム・リードは許可します。
読み取りコミット
このレベルは、ダーティー読み取りを禁止しますが、反復不能読み取りおよびファントム・リードは許可します。
読み取りアンコミット
このレベルは、ダーティー読み取り、反復不能読み取り、およびファントム・リードを許可します。
コンテナーは、以下のトランザクション分離レベル属性を使用します。
クライアントがトランザクション・コンテキストの外側から Bean メソッドを呼び出す場合は、コンテナーは、「サポートしません」というトランザクション属性が設定された場合と同じように動作します。 クライアントは、トランザクション・コンテキストなしでメソッドを呼び出す必要があります。
必須
この有効な値は、コンテナーが、常にクライアントに関連するトランザクション・コンテキスト内から Bean メソッドを呼び出すように指示します。 クライアントがトランザクション・コンテキストなしで Bean メソッドを呼び出そうとする場合は、コンテナーは、
javax.jts.TransactionRequiredException 例外をクライアントにスローします。トランザクション・コンテキストは、Enterprise Bean メソッドがアクセスするすべての Enterprise Bean オブジェクトまたはリソースに渡されます。
これらのエンティティー Bean にアクセスする Enterprise Bean クライアントは、既存のトランザクション内でこれを行う必要があります。 他の Enterprise Bean の場合、Enterprise Bean または Bean メソッドは、「Bean 管理」値を実装するか、または「必須」か「新規属性が必要」値を使用する必要があります。 Enterprise Bean ではない EJB クライアントの場合、クライアントは、javax.transaction.UserTransaction インターフェースを使用して、トランザクションを呼び出す必要があります。
新規属性が必要
この有効な値は、クライアントがメソッドをトランザクション・コンテキストの内側または外側のどちらから呼び出すかに関係なく、コンテナーが常に新規のトランザクション・コンテキスト内から Bean メソッドを呼び出すように指示します。 トランザクション・コンテキストは、この Bean メソッドが使用するすべての Enterprise Bean オブジェクトまたはリソースに渡されます。
必須
この有効な値は、コンテナーがトランザクション・コンテキスト内から Bean メソッドを呼び出すように指示します。 クライアントがトランザクション・コンテキスト内から Bean メソッドを呼び出す場合は、コンテナーはクライアントのトランザクション・コンテキスト内の Bean メソッドを呼び出します。クライアントがトランザクション・コンテキストの外側から Bean メソッドを呼び出す場合は、コンテナーは新規のトランザクション・コンテキストを作成し、そのコンテキスト内から Bean
メソッドを呼び出します。トランザクション・コンテキストは、この Bean メソッドが使用するすべての Enterprise Bean オブジェクトまたはリソースに渡されます。
サポートします
この有効な値は、クライアントが Bean メソッドをトランザクション内から呼び出す場合、コンテナーがトランザクション・コンテキスト内から Bean メソッドを呼び出すように指示します。 クライアントが Bean メソッドをトランザクション・コンテキストなしで呼び出す場合、コンテナーはトランザクション・コンテキストなしで Bean メソッドを呼び出します。 トランザクション・コンテキストは、この Bean メソッドが使用するすべての Enterprise Bean オブジェクトまたはリソースに渡されます。
サポートしません
この有効な値は、コンテナーがトランザクション・コンテキストなしで Bean メソッドを呼び出すように指示します。 クライアントがトランザクション・コンテキスト内から Bean メソッドを呼び出す場合は、コンテナーは Enterprise Bean インスタンスでメソッドを呼び出す前に、トランザクションと現行スレッド間のアソシエーションを中断します。その後、コンテナーは、メソッドの呼び出しが戻ったときに、中断状態のアソシエーションを再開します。 中断状態のトランザクション・コンテキストは、この Bean メソッドが使用するどの Enterprise Bean オブジェクトまたはリソースにも渡されません。
Bean 管理
この値は、Bean クラスが直接、トランザクションの切り分けを処理することをコンテナーに通知します。このプロパティーは、個々の Bean メソッドではなく、セッション Bean に対してのみ指定できます。
Java ガーベッジ・コレクションをテストすることによって、どのようにアプリケーションがメモリーを使用するか理解できます。ガーベッジ・コレクションは Java の強みです。メモリー管理の重荷をアプリケーション作成者から解放することによって、Java アプリケーションは、ガーベッジ・コレクション機能を持たない言語で作成されたアプリケーションよりも堅固になります。 ただし、この堅固さが生かされるのは、アプリケーションがオブジェクトを過剰に使用していない場合に限ります。ガーベッジ・コレクションは通常、適正に機能する WebSphere アプリケーションの合計実行時間の 5 〜 10% を消費します。 管理を行わないと、特に SMP サーバー・マシンを実行する場合、ガーベッジ・コレクションがアプリケーションにとって最大のボトルネックの 1 つになる可能性があります。
ガーベッジ・コレクションを使用して、アプリケーションのパフォーマンスの状態を評価します。 固定ワークロードの実行中にガーベッジ・コレクションをモニターすることによって、アプリケーションがオブジェクトを使いすぎているかどうか理解できるようになります。 ガーベッジ・コレクションは、メモリー・リークがあるかどうか検出するためにも使用できます。
リソース・アナライザーのガーベッジ・コレクションとヒープ統計を使用して、アプリケーションのパフォーマンスの状態を評価します。ガーベッジ・コレクションをモニターすることによって、メモリー・リークおよびオブジェクトの過剰使用を検出できます。
このタイプの検査を行う場合は、ヒープ・サイズの最小値と最大値を同じ値にします。実動環境での使用状況にできるだけ一致する (ユーザー・エラーなど)、繰り返しの多い代表的なワークロードを選択します。また、アプリケーションの状態が安定するまで、数分間アプリケーションを稼働させておくことも重要です。
意味のある統計値を得るために、アプリケーションが安定するまでは、固定ワークロードを実行してください。 これには、通常、少なくとも数分間掛かります。アプリケーションがオブジェクトを過剰に使用していないかどうか検査するには、リソース・アナライザーの JVMPI プロファイラーのカウンターを調べます。 ガーベッジ・コレクションの呼び出し間隔の平均は、ガーベッジ・コレクション 1 回分の平均所要時間の 5 〜 6 倍です。 そうしないと、アプリケーションがガーベッジ・コレクションに費やされる時間は、実行時間の 15% を超えます。また、解放、割り振り、および移動されたオブジェクトの数も調べてください。
ガーベッジ・コレクションのボトルネックを示す情報がある場合、ボトルネックを解消する方法は 2 つあります。最もコストのかからない方法は、オブジェクト・キャッシュとプールをインプリメントしてアプリケーションを最適化することです。 Java プロファイラーを使用して、ターゲットにするオブジェクトを決定します。アプリケーションを最適化できない場合は、メモリー、プロセッサー、およびクローンの追加が役に立つことがあります。メモリーを追加することによって、各クローンが妥当なヒープ・サイズを維持できるようになります。プロセッサーを追加すると、クローンを並列に実行できます。
メモリー・リークは、Java ではガーベッジ・コレクションのボトルネックの原因となる危険な状況です。メモリー・リークは最終的にシステムの不安定性につながるため、メモリーの過剰使用よりも悪質です。 時間が経過するにつれて、ガーベッジ・コレクションが頻繁に発生し、最終的にヒープが使い尽くされ、Java は致命的なメモリー不足 (Out of Memory) 例外により停止します。 メモリー・リークは、不必要なオブジェクトが参照され、削除されないときに起こります。これは、ハッシュ・テーブルなどの集合クラスでよく発生します。その理由は、テーブル自身が、すべての実際の参照情報が削除されていても、常にそのオブジェクトを参照するためです。
アプリケーションを実動環境に配置した直後にアプリケーションが破損するという問題がよくあります。多くはワークロードが高いことが原因です。リークが起こっているアプリケーションにおいて、ワークロードが高いためにリークの拡大が加速し、メモリー割り振りが失敗する場合に、特に当てはまります。
メモリー・リークのテストは、拡大する数に関連しています。 メモリー・リークは数バイトから数 K バイトの大きさのため、ガーベッジ・コレクションでは検出されません。 使用できるおよび使用できないと予測されるメモリーのサイズとこの量を区別するのは難しい作業です。 数が拡大することによってギャップが大きくなり、矛盾を簡単に認識できるようになると、この作業はより簡単になります。メモリー・リークについての重要事項を、以下にまとめます。
反復テストは、システム・レベルまたはモジュール・レベルで使用できます。 モジュラー・テストの利点は、管理の点でより優れていることです。 モジュール内で行われるすべてのものがそのモジュール専用であり、メモリーの使用など、外部の副次作用が発生しないようにモジュールを設計した場合、メモリー・リークのテストは一層簡単になります。最初に、モジュールを実行する前のメモリー使用量が記録され、決められたテスト・ケースのセットが実行されます。 テストの実行が終了すると、現行のメモリー使用量がかなり変更になっている場合、直前に記録し検査したメモリー使用量が繰り返し現行のメモリー使用量になります。 実際のメモリー使用量を記録する場合、ガーベッジ・コレクションを強制的に行う必要があることを覚えておいてください。 これを行うには、ガーベッジ・コレクションを実行したいモジュールに、System.gc() を挿入するか、このイベントの発生を強制するプロファイル作成ツールを使用してください。
メモリー・リークのテストにおいて、使用するテスト・ケースを選択するときに、以下を考慮してください。
リソース・アナライザーは、メモリー・リークの存在を判別するために役立ちます。最良の結果を得るには、ワークロードの期間を増やしながら (たとえば、1000、2000、および 4000 ページの要求) 実験を繰り返してください。 リソース・アナライザーのメモリー使用量のグラフは、ぎざぎざの形状になっている必要があります。グラフの落ち込んでいる部分は、それぞれガーベッジ・コレクションに対応しています。次のいずれかの現象が発生している場合は、メモリー・リークが起こっています。
負荷が高い間にリークが起こった可能性があることがヒープの消費に表れているが (アプリケーション・サーバーは、常に CPU 使用率が 100% 近くになっている)、その後、負荷が低いかほとんどアイドル状態になった間にヒープが回復するようなときは、これはヒープがフラグメント化していることを表しています。 JVM がガーベッジ・コレクションのサイクル中にメモリー割り振り要求を満たすために十分な量のオブジェクトを解放することができたとしても、ヒープ内の小さな空きメモリー域を圧縮して、連続するより大きなスペースを作成する時間がない場合に、ヒープのフラグメント化は起こる場合があります。
その他、小さなオブジェクト (512 バイトより小さい) が解放された場合にも、ヒープのフラグメント化が起こります。オブジェクトは解放されますが、ストレージは回復しないので、メモリーのフラグメント化が起こります。
ヒープのフラグメント化は、JVM 拡張設定コマンド行の引き数で -Xcompactgc フラグをオンにすることによって、回避できます。 -Xcompactgc を使用することで、パフォーマンスは少し悪化しますが、各ガーベッジ・コレクションのサイクルによって確実にフラグメント化が除去されます。
Java ヒープ・パラメーターも、ガーベッジ・コレクションの動作に影響します。ヒープ・サイズを増やすと、作成できるオブジェクトの数が増えます。大きなヒープは満杯になるまでに時間がかかるので、ガーベッジ・コレクションが実行されるまでにアプリケーションが稼働する時間が長くなります。ただし、大きなヒープは圧縮にも時間がかかるので、ガーベッジ・コレクションの所要時間も長くなります。
この図は、3 つの CPU プロファイルを示し、それぞれ固定ワークロードで Java ヒープ設定値を変えながら稼働しています。中央のプロファイルでは、初期ヒープ・サイズと最大ヒープ・サイズは 128MB に設定されています。ガーベッジ・コレクションは 4 回行われています。ガーベッジ・コレクションの合計時間は、合計実行時間の約 15% です。ヒープ・パラメーターを倍の 256MB にすると、一番上のプロファイルのように、ガーベッジ・コレクション間の作業時間の長さが増えていきます。ガーベッジ・コレクションは 3 回しか行われていませんが、それぞれのガーベッジ・コレクションの長さも増大しています。 3 番目のグラフでは、ヒープ・サイズが 64MB に削減され、逆の結果が示されています。 小さいヒープの場合、ガーベッジ・コレクション間の時間と各ガーベッジ・コレクションの時間はどちらも短くなっています。これらの 3 つの構成すべてについて、ガーベッジ・コレクションの合計時間は、約 15% です。このことは、Java ヒープとそのオブジェクト使用率に対する関係についての重要な概念を示しています。Java アプリケーションには、常にガーベッジ・コレクションのコストがかかります。
一連のテスト実験を、Java ヒープ設定値を変えながら実行します。たとえば、128MB、192MB、256MB、および 320MB で実験を行います。各実験の間、合計メモリー使用量をモニターします。ヒープをあまり拡張しすぎると、ページングが起こります。 (vmstat コマンドまたは Windows NT/2000 パフォーマンス・モニターを使用して、ページングを調べてください。) ページングが起こったら、ヒープのサイズを減らすか、またはシステムにメモリーを追加してください。実行がすべて終了したら、以下の統計値を比較してください。
ヒープの解放が 85% 以上になる場合、アプリケーション・サーバーおよびアプリケーションがヒープに割り振られたメモリーを十分に使用していないため、ヒープ・サイズの最大値を小さくすることを考慮してください。
Solaris tcp_close_wait_interval/tcp_time_wait_interval
Solaris tcp_fin_wait_2_flush_interval
Solaris tcp_keepalive_interval
他にも多数の TCP パラメーターが存在します。これらのパラメーターを変更すると、環境のパフォーマンスに影響が及ぶことがあります。 TCP/IP スタックのチューニングの詳細は、Web サイト「Tuning your TCP/IP Stack and More」を参照してください。
これら 3 つの TCP パラメーターを変更するまでは、サーバーはピーク期間に低速になっていました。 netstat コマンドの表示によれば、ポート 80 に対してオープンしている多数のソケットが、CLOSE_WAIT または FIN_WAIT_2 の状態でした。
両方のトポロジーにおいて、オブジェクト・リクエスト・ブローカーの参照による受け渡しが選択され、バックエンドのデータベースは独自の専用マシン上にあります。
さらに、4 つのマシンのプロセッサー使用率が 100% 近くである場合、5 番目のマシンを追加することもできます。 あるいは、Web サーバー・ボックスがフルに稼動しておらず、Web コンテナー処理が大量に行われていない場合は、トポロジー B に変更して 4 番目のマシンのプロセッサーを解放してください。
同じ関係が、接続のセッション・マネージャー数にも適用されます。
MaxAppls の設定は、少なくとも接続の数と同じか、それ以上にする必要があります。セッションとデータ・ソース用に同一のデータベースを使用している場合、
MaxAppls は、セッション・マネージャーとデータ・ソース用の接続の数の設定値の合計です。
MaxAppls = (データ・ソースに対して設定されている接続数 + セッション・マネージャーの接続数) x クローン数
WAS データベースと各アプリケーション・データベース用 MaxAppls の設定値を計算した後で、 DB2 用 MaxAgents の設定が、MaxAppls すべての合計と同じかそれ以上であることを確かめてください。
MaxAgents = 全データベースの MaxAppls の合計
このセクションでは、アプリケーション・サーバーを稼働させるハードウェアを選択し、構成するときの考慮事項を説明します。
各プロセッサーごとに、少なくとも 512MB のメモリーを確保します。
管理クライアント・ホストでのホスト名解決に関する詳細については、ホワイト・ペーパー「WebSphere Application Server Admin Best Practices for Performance and Scalability」を参照してください。
このセクションでは、サーバー環境でオペレーティング・システムをチューニングするときの考慮事項について説明します。
注: Windows NT/2000 オペレーティング・システムで WebSphere Application Server をチューニングする際は、この 2 つのパラメーターを一緒に使用する必要があります。
ulimit -n 2000クローンが稼働中の大型 SMP マシンの場合は、次のコマンドを実行します。
ulimit -unlimited
システム・リソースの制限すべての現行値を表示するには、コマンド ulimit -a を使用します。
ulimit -n 1024
システム・リソースの制限すべての現行値を表示するには、 ulimit -a を使用します。
一定のピークの間は、サーバーが停止することがあります。こうなった場合、netstat コマンドを使用すると、ポート 80 に対してオープンされたソケットの多くが、CLOSE_WAIT 状態または FIN_WAIT_2 状態になっていることが分かります。目に見える遅延が 4 分間にもわたって発生し、その間サーバーは応答をまったく送信しませんでしたが、システム・プロセスのアクティビティー全体によって CPU の使用率は常に高い状態でした。
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 60000
ピークの間は、サーバーが停止することがあります。 netstat コマンドを使用すると、ポート 80 に対してオープンされたソケットの多くが、CLOSE_WAIT 状態または FIN_WAIT_2 状態になっていることが分かります。目に見える遅延が 4 分間にもわたって発生し、その間サーバーは応答をまったく送信しませんでしたが、システム・プロセスのアクティビティー全体によって CPU の使用率は常に高い状態でした。
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval ndd -set /dev/tcp tcp_keepalive_interval 300000
次に示すような、他の Solaris TCP パラメーターの変更による成功例がお客様から報告されています。
tcp_conn_req_max_q tcp_comm_hash_size tcp_xmit_hiwat
これらの設定値を高く設定した後でパフォーマンスに大きな変化がなくても、システムには良い効果をもたらす可能性があります。
次のように、/etc/system 項目を設定します。
set semsys:seminfo_semume = 1024
次のように、/etc/system 項目を設定します。
semsys:seminfo_semopm = 200
HP-UX 11 の設定値を変更して、WebSphere Application Server のパフォーマンスを著しく向上させることができます。
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
このコマンドの出力によって、実行可能なプロセスのオペレーティング・システムの特性を表示します。
この変更の詳細については、Hewlett Packard の Web ページを参照してください。
connect requests dropped due to full queue
ndd -set /dev/tcp tcp_conn_request_max 1024
この変更について詳しくは、Hewlett Packard の Web ページを参照してください。
| カーネル・パラメーター | WebSphere Application Server チューニング | DB2 チューニング | Oracle チューニング |
| maxdsiz | 調整不要 | 調整不要 | 調整不要 |
| maxdsiz_64b | 調整不要 | 調整不要 | 調整不要 |
| maxuprc | 512 | ||
| maxfiles | 2,048 | ||
| maxfiles_lim | 2,048 | ||
| nkthreads | 10,000 | ||
| max_thread_proc | 2,048 | ||
| nproc | 1,028 | ||
| nflocks | 8,192 | ||
| ninode | 2,048 | ||
| nfile | 8,192 | ||
| msgseg | 32,767 | ||
| msgmnb | 65,535 | ||
| msgmax | 65,535 | ||
| msgtql | 1,024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1,024 | 200 | |
| semmnu | 1,024 | ||
| shmmax | 966,367,642 | 1 GB | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
HP-UX 11 のカーネル・パラメーターについて詳しくは、 Hewlett Packard の Web ページを参照してください。
WebSphere Application Server 製品は、数種類の Web サーバーのブランドおよびバージョン用のプラグインです。 Web サーバーとオペレーティング・システムの組み合わせごとに、アプリケーション・パフォーマンスに影響する特定のチューニング・パラメーターがあります。
このセクションでは、Web サーバーに関連したパフォーマンス・チューニングの設定値について説明します。
IHS はマルチプロセス、シングル・スレッドのサーバーです。詳細については、Tuning the IBM HTTP Server に関する Web ページを参照してください。
iPlanet Web Server エンタープライズ版のデフォルト構成では、単一プロセス、マルチスレッドのサーバーが提供されます。
Web サーバーが減速しているかどうか判別するには、 perfdump 統計を調べます。 次のデータを見てください。
注: 必要な場合は、次のようにして sePlugin の許可を調べます。
ListenBackLog パラメーターを使用して、IIS がキュー内に保持する要求の数を増やし、この条件を緩和してください。
MaxPoolThreads、PoolThreadLimit
IBM HTTP Server は簡単に構成されます。通常はデフォルト設定値が適しています。
スレッド使用率を表示する方法: 負荷がかかっていて使用中のスレッド数を知るには、次の 2 つの方法があります。
IBM HTTP Server のサーバー状況を使用するには、以下のステップに従ってください。
各 WebSphere Application Server のプロセスには、アプリケーション・パフォーマンスに影響を与える幾つかのパラメーターがあります。 WebSphere Application Server 製品の各アプリケーション・サーバーは、 EJB コンテナーと Web コンテナーから構成されます。
管理ドメイン内のアプリケーション、Web コンテナー、EJB コンテナー、アプリケーション・サーバー、およびノードの構成とチューニングを行うには、WebSphere Application Server 管理コンソールを使用します。
パラメーターの使用率を調べる方法: UNIX では、ps -efl コマンドを使用して現行のプロセスの優先順位を調べます。
サーブレットの要求を Web サーバーから Web コンテナーに発送するために、この製品は、Web サーバー・プラグインと各 Web コンテナー間のトランスポート・キューを確立します。
リソース・アナライザーは、構成されたスレッドが使用状態にある時間量を判別する、Percent Maxed というメトリックを表示します。この値が常に 2 桁ならば、Web コンテナーがボトルネックの可能性があり、スレッド数の増加が必要です。
要求されたサイズのキャッシュは、各スレッドごとに作成されます。スレッドの数は、Web コンテナーの最大スレッド・サイズの設定値によって決まります。
注: キャッシュを大きくすると、使用される Java ヒープが増えるので、最大 Java ヒープ・サイズも増やさなければならない場合があります。たとえば、各キャッシュ項目に 2KB が必要で、最大スレッド・サイズが 25 に設定されており、URL 呼び出しキャッシュ・サイズが 100 の場合は、 5MB の Java ヒープが必要です。
リソース・アナライザーを使用して、Bean パフォーマンス情報を表示します。
Bean、許可、およびクリデンシャルに関するセキュリティー情報は、キャッシュされます。キャッシュ・タイムアウトが満了すると、キャッシュされた情報はすべて無効になります。その後に続く情報の要求は、データベース・ルックアップということになります。情報の獲得には、Lightweight Directory Access Protocol (LDAP) バインドまたはネイティブ認証の呼び出しが必要になることがあります。ただし、どちらもパフォーマンスの観点で相対的にコストがかかる操作です。
サイトの使用パターンとセキュリティーの必要性に応じて、アプリケーションに最良のトレードオフを実地試験によって見付けます。
以下のシステム・プロパティーで、キャッシュの 1 次および 2 次 Hashtable の初期サイズを判別します。これは、再ハッシュの頻度と、ハッシュ・アルゴリズムの分散に影響します。使用可能なハッシュ値が大きくなるほど、ハッシュ衝突が発生する確率は少なくなり、検索時間は遅くなる傾向にあります。幾つかの項目でキャッシュ Hashtable を構成する場合は、大きな容量のテーブルを作成しておくと、自動再ハッシュの判断でテーブルを大きくするよりも、効率的に項目を挿入することができます。再ハッシュを行うと、そのたびにすべての項目が移動します。
セキュア・アソシエーション・サービス (SAS) 機能は、JVM の外部に出る (別の JVM に接続する) 場合だけ、SSL 接続を確立することに注意してください。 したがって、すべての Bean が同じ JVM 内に配置されている場合は、 SAS によって SSL が使用されていてもパフォーマンスは低下しません。
これらのパラメーターを設定するには、「サービス (Services)」タブを使用し、デフォルト・サーバー、または管理ドメイン内で構成する別の Application Server に対して、オブジェクト・リクエスト・ブローカーの「プロパティーを編集 (Edit Properties)」を使用します。
警告: 参照による受け渡しは予期しない結果を招くことがあり、危険です。リモート・メソッドによってオブジェクト参照子が変更されると、呼び出し側が変更の影響を受けることがあります。
アプリケーション・サーバーが予測する Enterprise Bean 要求のワークロードが大きい場合は、ORB 構成が重要です。以下のプロパティーに注意してください。
JNIReader を使用する場合は、固定されたセットのスレッドを作成する必要があり、必要なメモリーはさらに下回ります。スレッドは、初期化の際に一度作成されるのみで、破棄されることはないので、時間も節約されます。 JNIReader は C ネイティブ・インプリメンテーションで、デフォルトのリーダー・スレッドより高速でなければなりません。
重要: JNIReader の JNI ライブラリー・インプリメンテーションが WebSphere Application Server の bin ディレクトリー内にあることを確認します。ライブラリーは、Intel プラットフォームの場合は Selector.dll、UNIX の場合は libSelector.a または libSelector.so です。 UNIX の場合、接頭部 "lib" が欠落している場合は、ファイル名の変更が必要です。
JVM のチューニング
JVM は、WebSphere Application Server (主として Java アプリケーション) およびユーザーのアプリケーションのパフォーマンスに影響する、いくつかのチューニング・パラメーターを提供します。
一般に、Java ヒープのサイズを増やすと、物理メモリー中にヒープが存在しなくなるまでは、スループットが向上します。ディスクへのヒープのスワッピングが開始されると、Java パフォーマンスは大幅に低下します。したがって、最大ヒープ・サイズは、物理メモリー内にヒープが収まるように小さく設定する必要があります。
物理メモリーの使用量は、JVM や他のアプリケーション (たとえば、データベース) によって共用されます。安全のために、小さいヒープを使用することをお勧めします (たとえば、メモリーの少ないマシンでは 64MB)。
小規模なマシン (つまり、物理メモリーが 1GB 未満) では 128MB、 2GB のメモリーがあるシステムでは 256MB、大規模なシステムでは 512MB の最大ヒープを試してください。 アプリケーションによって、出発点は異なります。
パフォーマンス試験を行うときに、再現性の高い結果が必要な場合は、初期サイズと最大サイズを同じ値に設定します。これによって、稼働中にヒープが増加しなくなります。実動システムで、Java アプリケーションの実効セットのサイズがよく分かっていない場合、出発点として初期化値を最大設定値の 1/4 にすることをお勧めします。 JVM は、ヒープのサイズを Java アプリケーションの実効ページ・セットに適合させることを試行します。
デフォルト・サーバー、または管理可能ドメイン内で構成する別のアプリケーション・サーバーのコマンド行プロパティーを使用して、JVM パラメーターを設定します。
WebSphere Application Server は、ユーザーが選択しサポートされているデータベースと固く統合されています。サポートされているデータベース製品については、製品の前提条件 Web サイト (www.ibm.com/software/webservers/appserv/library.html) を参照してください。 WebSphere Application Server は、管理用の永続的な支援記憶装置として、また、セッション状態およびアプリケーション用 Enterprise Bean のデータを保管するために、データベースを使用します。
アプリケーションが、WebSphere Application Server セッション状態、JDBC データベース接続プーリングまたは Enterprise Bean を使用する場合は、これらのリソースおよびデータベース設定を管理可能ドメイン内で構成する方法に、特に注意してください。 WebSphere Application Server のインストールの際、WASnn というデータベースが設定されます (nn はリリース ID) が、別の名前を使用することもできます。本書では、WAS40 の使用を前提とします。
スケーラビリティーについては、クラスター化を使用している場合は特に、別のマシン上にデータベースを設定することが適切です。このことは、ユーザーの WebSphere Application Server データベース、アプリケーション・データベース、および WebSphere Application Server セッション・データベース (持続セッションを使用している場合) に関係しています。
クローンが使用される場合は、クローンごとに 1 つのデータ・ソース・プールが存在します。このことは、データベース・サーバーの最大接続数を構成する際に重要です。
以上の数を削減できるプール接続に最適な数を見つけるには、リソース・アナライザーを使用します。使用パーセントが著しく低い場合は、プール内の接続数を減らすことを考慮します。
UNIX プラットフォームでは、各接続ごとに別の DB2 プロセスが作成されます。このため、メモリーの少ないシステムの場合はパフォーマンスがすぐに低下し、エラーが発生することがあります。
エンティティー EJB トランザクションごとに、特にトランザクションを処理するためのデータベースへの追加接続が必要です。データ・ソース接続数を計算するときは、必ずこのことを考慮に入れてください。アプリケーションがスレッド当たり 2 つ以上の同時接続を要求し、 かつ、データベース接続プールがスレッド数に対して十分に確保されていない場合、デッドロックが起こることがあります。アプリケーションの各スレッドが 2 つの同時データベース接続を要求し、スレッドの数が最大接続プール・サイズに等しい場合を想定します。 次の両方の条件が満たされると、デッドロックが発生します。
この場合、デッドロックが起こらないようにするには、データベース接続プールに対して設定する値を少なくとも 1 つ大きくします。こうすると、待機中のスレッドの少なくとも 1 つが 2 番目のデータベース接続を完了できるので、データベース接続が解放されます。
デッドロックを回避するには、スレッド当たり多くて 1 つの接続を使用するようにアプリケーションをコーディングします。スレッド当たり C の同時データベース接続を要求するようにアプリケーションをコーディングする場合、接続プールは少なくとも以下の接続数をサポートする必要があります。ここで、T はスレッドの最大数です。
T * (C - 1) + 1
接続プールの設定値は、データベース・サーバーがサポートするように構成されている接続の数に、直接関係しています。プール内の接続の最大数を上げて、データベース内の対応する設定値を上げない場合、アプリケーションに障害が起こり、stderr.log ファイルに SQL 例外エラーが表示されます。
注: 準備済みステートメントは、プリコンパイルの利点を生かすことができる、パラメトリック SQL ステートメントの処理に最適です。 データ・ソース内で指定された JDBC ドライバーがプリコンパイルをサポートする場合、準備済みステートメントを作成すると、そのステートメントはプリコンパイル用データベースに送信されます。ドライバーによっては、プリコンパイルをサポートしていないものもあります。この場合は、準備済みステートメントが実行されるまで、そのステートメントはデータベースに送信されません。
WebSphere Application Server データ・ソースは、データベース接続のプールおよび準備済みステートメント・オブジェクトの関連したキャッシュを管理します。準備済みステートメントは、それらを実行する各接続を識別するタグとともにキャッシュに入れられます。使用される SQL ステートメント、準備済みステートメントのキャッシュ、データ・ソースおよびデータベースの関係は、検討すべき重要なポイントです。アプリケーションが 5 つの SQL ステートメント (2 つは選択、1 つは削除、1 つは挿入および 1 つは更新) を使用するとします。
上記のデータ・ソースは、データベースへ最大 3 つの同時接続ができるように構成されます。接続はすでに作成されており、多数の SQL ステートメントが実行されました。準備済みステートメントのキャッシュは、10 ステートメントを保持するように構成されました。接続 1 および 2 のために、3 つの準備済みステートメントがキャッシュされています。接続 3 には、4 ステートメントがキャッシュされています。ステートメントがコンパイルされて準備済みステートメントになるため、準備済みステートメントのキャッシュは、アプリケーションのデータベース使用パターンを反映しています。準備済みステートメントのキャッシュは、先入れ先出し法 (FIFO) キューをインプリメントします。所定の SQL ステートメントを表す準備済みステートメント・オブジェクトは、準備済みステートメントのキャッシュ内に複数回現れることがあります。特に、接続ごとに 1 回、接続プール内に現れることがあります。たとえば、ステートメント 1 および 2 は、各接続ごとに 1 回、合計 3 回現れます。ステートメント 3 は、接続 3 の場合は現れず、また、ステートメント 4 および 5 は、接続 3 の場合のみ現れます。したがって、ステートメント 4 および 5 が接続 1 および 2 で発生する場合、実行時間が少し長くなります。これは、接続のために再コンパイルする必要があるためです。この例でのより良い代替策は、準備済みステートメントのキャッシュのサイズを 15 (3 つの接続ごとに 5 つの準備済みステートメント) に設定することです。
リソース・アナライザーは、この設定値をチューニングして、キャッシュの廃棄を最小限に抑えるのに役立ちます。着信クライアント要求の典型数を表す標準のワークロード、反復の固定数、そして標準セットの構成設定値を使用します。
リソース・アナライザーを使用するには、以下の指示に従います。
「データ・ソース (Data source)」 > 「接続のプール (Connection Pooling)」 > 「ステートメントのキャッシュ・サイズ (Statement Cache Size)」に対する最適な値は、ゼロの値か、PrepStmt Cache Discard の最低値のいずれかを得るために使用される設定値です。これは、代表的なワークロードの最も効果的な数を示します。
その他の JDBC パラメーター
準備済みステートメント・キャッシュのサイズに加えて、他の
JDBC ドライバー固有のプロパティーを設定できます。たとえば、Oracle を使用する場合、行の数を増やして、以下のステートメントで結果を取得している間に取り出すことができます。
name="defaultRowPrefetch", value="25"
このタイプのカスタム・プロパティーは、データベースの「一般 (General)」タブに入力します。
BUFFPAGE を n の値に設定するには、DB2 コマンド update db cfg for x using BUFFPAGE n を出して、以下のように、必ず NPAGES が -1 になるようにしてください。
db2 <-- DB2 コマンド・モードにします。そうしない場合は、以下にある "select" がそのまま機能しません。
connect to x <-- (ここで x は特定の DB2 データベース名です)
select * from syscat.bufferpools
(デフォルト名に注意、おそらく IBMDEFAULTBP)
(NPAGES がすでに -1 の場合は OK で、次のコマンドを発行する必要はありません)
alter bufferpool IBMDEFAULTBP size -1
(上記の "select" を再発行し、NPAGES は -1 でなければなりません)
最適化レベルを 9 に設定すると、DB2 は多くの時間とすべての統計データを投入して、アクセス・プランを最適化します。
詳しくは、DB2 の資料、および IBM DB2 Web サイトを参照してください。
runstats が実行されたかどうかを調べるために、DB2 CLP に以下のコマンドを出します。
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
runstats が実行されていなければ、nleaf および nlevels には -1 が入り、stats_time には空の項目 "-" が入ります。
runstats がすでに実行された場合は、runstats が完了した時点のリアルタイム・スタンプも stats_time の下に表示されます。前の runstats で表示された時刻が古すぎると考えられる場合は、もう一度 runstats を実行してください。
新しい設定は、ただちに発効します。
以下に、DB2 MinCommit に関連する幾つかのメトリックを示します。
セッション管理パラメーターの設定について詳しくは、インフォセンターの項目 4.4.1.1 Session programming model and environment を参照してください。
このパラメーターの使用効率は、cmm コンポーネントのトレースを可能にすると調べることができます。
メッセージを連続して処理したい場合 (つまり、メッセージ Bean インスタンスを 1 つだけ使用して次々にメッセージを処理したい場合) は、1 の値を使用する必要があります。
値を 20 にすると、スループットは最高になります。これを超える値にしても、スループットは向上しません。メッセージ・タイプ、作業量、および使用可能なリソースを基に、10 と 20 の間の値を使用して、最大のメッセージ・スループットを取得する必要があります。
メッセージ・スループットの増加は、システム・リソースおよび listener 構成などのさまざまな要因によって変わります。システム・リソースは、プロセッサーの数と能力に関係があります。 listener 構成は、使用されるセッション数と JMS の相互作用です。 JMS の相互作用には、基本的な MQ Server マネージャー・リソースへのアクセスを共用する場合のコンテンションが含まれます。
以下のステップに従ってください。
「スタート (Start)」メニューから、「プログラム (Programs)」>
「管理ツール (Administrative Tools)」>「パフォーマンス・モニター
(Performance Monitor)」の順に選択します。