18 Webアプリケーションのチューニング

この章では、Webアプリケーションのチューニングとセッションの管理に関するベスト・プラクティスを示します。

ベスト・プラクティス
セッション管理
Pub-Subチューニング・ガイドライン

ベスト・プラクティス

ページ・チェックの無効化
カスタムJSPタグの使用
JSPのプリコンパイル
アクセス・ロギングの無効化
HTMLテンプレート圧縮の使用
サービス・レベル・アグリーメントの使用
関連情報

ページ・チェックの無効化

サーブレットおよびJDPのページ・チェックを無効化すると、パフォーマンスを向上できます。次の各パラメータを -1に設定します。

pageCheckSeconds
servlet-reload-check-secs
servlet Reload Check

これは本番モードではデフォルトの値です。

カスタムJSPタグの使用

Oracleでは、JSPページで使用できる特殊なJSPタグとして、cache、repeat、およびprocessの3つを提供しています。これらのタグは、weblogic-tags.jarというタグ・ライブラリjarファイルにパッケージされています。このjarファイルには、タグのクラスとタグ・ライブラリ記述子(TLD)が含まれています。これらのタグを使用するには、JSPを格納するWebアプリケーションにこのjarファイルをコピーして、タグ・ライブラリをJSPで参照します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のカスタムWebLogic JSPタグ(cache、process、repeat)の使い方に関する項を参照してください。

JSPのプリコンパイル

weblogic.xmlデプロイメント記述子のjsp-descriptor要素のprecompileパラメータをtrueに設定すると、Webアプリケーションをデプロイまたは再デプロイしたとき、あるいはWebLogic Serverを起動したときにJSPをプリコンパイルするように構成できます。サーバーを再起動するたびに、また追加でサーバーをターゲット指定したときに、JSPを再コンパイルしないようにするには、weblogic.jspcを使用してJSPをプリコンパイルし、プリコンパイルしたJSPをWEB-INF/classesフォルダにコピーして、.warファイルにアーカイブします。ソース・ファイルをアーカイブ.warファイルとは別のディレクトリに格納すると、クラス・ファイルのいずれかとJSPとの依存関係によってエラーが発生する可能性がなくなります。JSPを再コンパイルしないようにするには、「http://www.oracle.com/technology/pub/articles/dev2arch/2005/01/jsp_reloaded.html」の不必要なJSPコンパイルを避ける方法を参照してください。

アクセス・ロギングの無効化

access-logging-disabled要素を設定すると、基底のWebアプリケーションのアクセス・ロギングを不要にし、ロギングのオーバーヘッドを軽減することによってサーバーのスループットを向上させることができます。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「container-descriptor」を参照してください。

HTMLテンプレート圧縮の使用

compress-html-templateを使用すると、JSPテンプレート・ブロック内のHTMLが圧縮され実行時のパフォーマンスが向上します。JSPのHTMLテンプレート・ブロックに<pre> HTMLタグが含まれる場合は、この機能は有効にしないでください。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「jsp-descriptor」を参照してください。

サービス・レベル・アグリーメントの使用

ワーク・マネージャには、アプリケーションで必要とされるサーバー・レベル・アグリーメントに基づいてサーブレットやJSPを割り当てる必要があります。「スレッド管理」を参照してください。

セッション管理

セッションの永続性およびセッションを処理する場合、一般にはアプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化する必要があります。次の項では、環境やアプリケーションに適したセッション管理方法の設計について説明します。

セッションの永続性の管理
セッションの最小化
セッション・データの集約

セッションの永続性の管理

WebLogic Serverでは、Async-replicatedおよびAsync-JDBCモードを含めて、アプリケーションの異なる要件に応じる複数のセッション永続性メカニズムが用意されています。セッション永続性メカニズムは、後でWebアプリケーションに構成できます。アプリケーションのために使用するセッション管理方式は、HTTPセッション・サイズ、セッション・ライフサイクル、信頼性およびセッション・フェイルオーバー要件など実環境要因によって異なります。たとえば、Webアプリケーションのライフサイクルとオブジェクト・サイズに基づき、フェイルオーバー要件のないWebアプリケーションは、単一メモリーベースのセッションとして維持され、セッション・フェイルオーバー要件を持つWebアプリケーションは、レプリケートされたセッションまたはJDBCベース・セッションとして維持されます。

純粋なパフォーマンスという観点では、セッションの状態に対するJDBCベース永続性と比較して、レプリケートされたセッション永続性を選択する方がよい選択です。ただし、レプリケート・ベース・セッションでは、WebLogicクラスタリングを使用する必要があるので、単一サーバー環境ではこのオプションを選択しません。

一方、JDBCベースの永続性を使用した環境では、WebLogicクラスタを使用する必要はなく、セッションの状態をより長い期間にわたってデータベースに保持できます。JDBCベースの永続性のパフォーマンスを向上させるには、コードを最適化してセッションの状態の永続性の粒度をできるだけ高くします。また、データベースの選択、データベース・サーバーの適切な構成、JDBCドライバ、JDBC接続プールの構成なども、JDBCベースの永続性のパフォーマンスに影響します。

セッション永続性の管理の詳細については次を参照してください。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッション永続性の構成
『Oracle WebLogic Serverクラスタの使用』のHTTPセッションの状態のレプリケーション
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の永続記憶域(JDBC永続性)のデータベースの使用

セッションの最小化

アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Serverのセッション管理の方法を構成することが重要になります。次のことを考慮してください。

セッションの使用にはスケーラビリティのトレードオフが伴います。
セッションの使用を抑えます。つまり、ステートをクライアント上で現実的に保持できない場合か、またはURL書換えのサポートが必要な場合にのみ、セッションを使用します。たとえば、ユーザー名などの単純な状態を直接Cookieに保持します。また、ラッパー・クラスを記述して、これらのCookieの「取得」および「設定」を行うこともできます。これにより、同じプロジェクトに参加しているサーブレット開発者の作業が簡素化されます。
頻繁に使用する値をローカル変数に格納します。

詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッション管理の設定に関する項を参照してください。

セッション・データの集約

この項では、セッション・データの集約方法のベスト・プラクティスを紹介します。WebLogic Serverではセッションの変更を属性によって追跡およびレプリケートするので、以下のことを行う必要があります。

連携して変更するセッション・データは単一のセッション属性に集約します。
頻繁に変更するセッション・データと読取り専用のセッション・データは別のセッション属性に集約します。

たとえば1つの大きな属性を使用して、そこにすべてのセッション・データを含めている場合、そのデータの10 %だけを変更しても、属性全体をレプリケートする必要があります。この操作によって、不要なシリアライズ/デシリアライズやネットワークのオーバーヘッドが生じます。この場合、変更する10%のセッション・データを別の属性に移動する必要があります。

Pub-Subチューニング・ガイドライン

この項では、Pub-Subサーバーの一般的なチューニング・ガイドラインを示します。

特にアプリケーションが数千単位のクライアントを処理する場合は、ファイル記述子を増やして多数の接続が長時間維持されるようにします。
WebLogic Serverのロギング・レベルのチューニング
アクセス・ロギングを無効化します。
JVMオプションをチューニングします。推奨オプションは-Xms1536m -Xmx1536m -Xns512m -XXtlaSize:min=128k,preferred=256kです。
最大メッセージ・サイズを増やします。アプリケーションが大量のメッセージをパブリッシュする場合は、値を<max-message-size>10000000</max-message-size>に設定することを検討してください。