Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
![]() 戻る |
![]() 次へ |
以下の節では、Web アプリケーションのチューニングとセッションの管理に関するベスト プラクティスを示します。
サーブレットおよび JDP のページ チェックを無効化すると、パフォーマンスを向上できます。以下の各パラメータを -1 に設定します。
これはプロダクション モードではデフォルトの値です。
Oracle では、JSP ページで使用できる特殊な JSP タグとして、cache、repeat、および process の 3 つを提供しています。これらのタグは、weblogic-tags.jar
というタグ ライブラリ jar ファイルにパッケージされています。この jar ファイルには、タグのクラスとタグ ライブラリ記述子 (TLD) が含まれています。これらのタグを使用するには、JSP を格納する Web アプリケーションにこの jar ファイルをコピーして、タグ ライブラリを JSP で参照します。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「カスタム WebLogic JSP タグ (cache、process、repeat) の使い方」を参照してください。
weblogic.xml
デプロイメント記述子の jsp-descriptor
要素の precompile パラメータを true に設定すると、Web アプリケーションをデプロイまたは再デプロイしたとき、あるいは WebLogic Server を起動したときに JSP をプリコンパイルするようにコンフィグレーションできます。サーバを再起動するたびに、また追加でサーバを対象指定したときに、JSP を再コンパイルしないようにするには、weblogic.jspc
を使用して JSP をプリコンパイルし、プリコンパイルした JSP を WEB-INF/classes フォルダにコピーして、.war
ファイルにアーカイブします。ソース ファイルをアーカイブ .war
ファイルとは別のディレクトリに格納すると、クラス ファイルのどれかと JSP との依存関係によってエラーが発生するおそれがなくなります。JSP の再コンパイルを回避する方法の詳細については、「Avoiding Unnecessary JSP Compilation」(http://www.oracle.com/technology/index.html
) を参照してください。
access-logging-disabled
要素を設定すると、基底の Web アプリケーションのアクセス ロギングを不要にし、ロギングのオーバーヘッドを軽減することによってサーバのスループットを向上させることができます。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「container-descriptor
」を参照してください。
compress-html-template
を使用すると、JSP テンプレート ブロック内の HTML が圧縮され実行時のパフォーマンスが向上します。JSP の HTML テンプレート ブロックに <pre>
HTML タグが含まれる場合は、この機能は有効にしないでください。
『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「jsp-descriptor
」を参照してください。
ワーク マネージャには、アプリケーションで必要とされるサーバ レベル アグリーメントに基づいてサーブレットや JSP を割り当てる必要があります。「スレッド管理」を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「サーブレットのベスト プラクティス」
http://www.javaworld.com/javaworld/jw-06-2004/jw-0628-performance_p.html
にある『Servlet and JSP Performance Tuning』(Rahul Chaudhary 著、JavaWorld、2004 年 6 月号)
セッションの永続性およびセッションを処理する場合、一般にはアプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化する必要があります。以下の節では、環境やアプリケーションに適したセッション管理方法の設計について説明します。
Weblogic Server は、さまざまなアプリケーション要件に対応できるよう、5 つのセッション永続性メカニズムを備えています。セッション永続性メカニズムは、Web アプリケーション レイヤでコンフィグレーションできます。どのセッション管理戦略を選択するかは、HTTP セッションのサイズ、セッションのライフ サイクル、信頼性、セッションのフェイルオーバといった実際の要件によって異なります。たとえば、フェイルオーバが不要な Web アプリケーションであれば単一メモリ ベースのセッションとして管理でき、セッション フェイルオーバ機能を必要とする Web アプリケーションであれば、そのライフ サイクルやオブジェクト サイズに応じてレプリケート セッションまたは JDBC セッションとして管理できます。
純粋にパフォーマンスの面から言えば、セッション ステートの JDBC ベースの永続性よりも、インメモリ セッションの永続性の方が全般的に優れています。「Session Persistence Performance in WebLogic Server 7.0」(http://wldj.sys-con.com/read/42784.htm
) の著者によれば、「データのシリアライズとデシリアライズに伴う負荷はすべてのセッション永続性メカニズムで扱わなければなりませんが、データベース対話に伴う追加的な負荷は JDBC ベースのセッション永続性のパフォーマンスに影響し、インメモリ レプリケーションのパフォーマンスを下回る原因となります」。ただし、インメモリ ベースのセッション永続性は、WebLogic クラスタを使用する必要があるため単一サーバ環境では選択できません。
一方、JDBC ベースの永続性を使用した環境では、WebLogic クラスタを使用する必要はなく、セッション ステートをより長い期間にわたってデータベースに保持できます。JDBC ベースの永続性のパフォーマンスを向上させるには、コードを最適化してセッション ステートの永続性の粒度をできるだけ高くします。また、データベースの選択、データベース サーバの適切なコンフィグレーション、JDBC ドライバ、JDBC 接続プールのコンフィグレーションなども、JDBC ベースの永続性のパフォーマンスに影響します。
セッション永続性の管理の詳細については以下を参照してください。
『BEA WebLogic Developers Journal』の「Session Persistence Performance in WebLogic Server 7.0」(http://wldj.sys-con.com/read/42784.htm
)。WebLogic Server でサポートされている 5 つのセッション永続性メカニズムを詳細に比較しています。
『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「セッションの永続性のコンフィグレーション」
『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「HTTP セッション ステートのレプリケーション」
『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「データベースの永続ストレージとしての使い方 (JDBC 永続性)」
アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Server のセッション管理の方法をコンフィグレーションすることが重要になります。以下のことを考慮してください。
セッションの使用にはスケーラビリティのトレードオフが伴う。
セッションの使用を抑える。つまり、ステートをクライアント上で現実的に保持できない場合か、または URL 書き換えのサポートが必要な場合にのみ、セッションを使用します。たとえば、ユーザ名などの単純なステートを直接クッキーに保持します。また、ラッパー クラスを記述して、これらのクッキーの「取得」および「設定」を行うこともできます。これにより、同じプロジェクトに参加しているサーブレット開発者の作業が簡素化されます。
頻繁に使用する値をローカル変数に格納する。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「セッション管理の設定」を参照してください。
この節では、セッション データの集約方法のベスト プラクティスを紹介します。WebLogic Server ではセッションの変更を属性によって追跡およびレプリケートするので、以下のことを行う必要があります。
連携して変更するセッション データは単一のセッション属性に集約する。
頻繁に変更するセッション データと読み取り専用のセッション データは別のセッション属性に集約する。
たとえば 1 つの大きな属性を使用して、そこにすべてのセッション データを含めている場合、そのデータの 10 % だけを変更しても、属性全体をレプリケートする必要があります。この操作によって、不要なシリアライズ/デシリアライズやネットワークのオーバーヘッドが生じます。この場合、変更する 10% のセッション データを別の属性に移動する必要があります。
この節では、Pub-Sub サーバの一般的なチューニング ガイドラインを示します。
特にアプリケーションが数千単位のクライアントを処理する場合は、ファイル記述子を増やして多数の接続が長時間維持されるようにする。
ロギング レベルを [Warning] に設定する。
アクセス ロギングを無効化する。
JVM オプションをチューニングする。推奨オプションは -Xms1536m -Xmx1536m -Xns512m -XXtlaSize:min=128k,preferred=256k
です。
最大メッセージ サイズを増やす。アプリケーションが大量のメッセージをパブリッショする場合は、値を <max-message-size>10000000</max-message-size>
に設定することを検討してください。