コーディング手法の提案

この節では、サーブレットおよび JSP アプリケーションのパフォーマンスを改善するコーディング手法についてのヒントを示します。

一般的な指針

プレゼンテーション層のパフォーマンスを高めるには、次の一般的な指針に従います。

• サーブレット内での Java 同期を最小限にする。

• サーブレットでシングルスレッドモデルを使用しない。

• 負荷が大きい 1 回限りの初期化にはサーブレットの init() メソッドを使用する。

• System.out.println() 呼び出しの使用を避ける。

共有変更済みクラス変数を避ける

サーブレットのマルチスレッドモデル (デフォルト) では、個々のアプリケーションサーバーインスタンスに対して単一のサーブレットインスタンスが作成されます。そのアプリケーションインスタンス上のサーブレットに対するすべての要求は、同じサーブレットインスタンスを共有します。このことが原因で、サーブレットコードに同期ブロックが存在する場合にスレッド競合が発生する可能性があります。したがって、共有変更済みクラス変数は同期の必要性を作り出すため、使用を避けます。

HTTP セッション処理

HTTP セッションを使用するときは、次の指針に従います。

• セッションを作成しすぎないようにします。セッション作成には一定の負荷が伴います。不要な場合にはセッションを作成しないでください。

• セッションが不要になった時点で、javax.servlet.http.HttpSession.invalidate() を使用してセッションを解放します。

• 応答時間を短縮するために、セッションのサイズを小さく保ちます。可能であれば、セッションサイズを 7K バイト未満に保ちます。

• JSP ファイルで <%page session="false"%> 指令を使用して、セッションが必要でないときに Application Server が自動的にセッションを作成することを避ける。

• HttpSession で大きなオブジェクトグラフを避けます。大きなオブジェクトグラフは直列化を強制し、計算のオーバーヘッドを増加させます。一般則として、サイズの大きいオブジェクトを HttpSession 変数として格納しないでください。

• HttpSession にトランザクションデータをキャッシュしないでください。HttpSession 内のデータへのアクセスはトランザクション方式ではありません。このオブジェクトをトランザクションデータのキャッシュとして使用しないでください。トランザクションデータはデータベースに保持し、エンティティー Beans を使用してアクセスするほうが適切です。トランザクションは失敗時に元の状態にロールバックされます。ただし、古くなっていて正しくないデータが HttpSession オブジェクトに残る場合があります。Application Server では、読み取り専用データへのキャッシュを使用したアクセスのために、「読み取り専用」の Bean 管理による持続性エンティティー Beans が用意されています。

設定と配備のヒント

パフォーマンスを改善するには、設定に関する次のヒントに従います。これらのヒントは、開発環境ではなく本稼働環境を想定したものです。

• クラスのロード時間を短縮するには、サーバーの CLASSPATH に入れるディレクトリ数が多くなりすぎないようにします。アプリケーション関連クラスを JAR ファイルに置きます。

• 一般に、HTTP の応答時間は、キープアライブサブシステムおよび HTTP サーバーをどのように調整するかによって変化します。詳細は、「HTTP サービスの設定」を参照してください。

• Solaris 8 を使用している場合、ヒープ空間への同時アクセスのための malloc ルーチンのコレクションを提供する mtmalloc ライブラリを使用することによって SSL を最適化します。mtmalloc を使用するには、次の手順に従います。

  • SunSolve Online から、パッチ 111308-03 を入手してインストールします。

  • ドメインの bin/startserv ディレクトリにある startserv スクリプトを編集し、LD_PRELOAD 環境変数の値を /usr/lib/libmtmalloc.so と定義します。

    環境変数を定義するための正確な構文は、使用するシェルによって異なります。

• 可能な場合はサーブレットの結果をキャッシュします。詳細は、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の第 5 章「Developing Web Applications」を参照してください。

• アプリケーションに EJB コンポーネントが含まれない場合、アプリケーションを EAR ファイルでなく WAR ファイルとして配備します。

セキュリティーマネージャーの無効化

セキュリティーマネージャーは負荷が大きいアプリケーションです。これは、必要なリソースへの呼び出しで doPrivileged() メソッドを呼び出す必要があることに加えて、server.policy ファイルを使用してリソースをチェックする必要もあるためです。サーバー上で悪意のあるコードが実行されないという確証があり、アプリケーションの内部で認証を使用しない場合は、セキュリティーマネージャーを無効にすることができます。

server.policy ファイルの使用を無効にするには、管理コンソールを使用します。「設定」、「<設定名>」、「JVM 設定」(「JVM オプション」) の順に選択し、次のようなオプションを削除します。

-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy