第 3 章   アプリケーションのチューニング


この章では、最大のパフォーマンスを得るためにアプリケーションをチューニングする包括的な手順を示します。この章には次のトピックがあります。

• Java コーディングのガイドライン

• J2EE プログラミングのガイドライン

Java コーディングのガイドライン

この節では、Java コーディングに関する事項とパフォーマンスに関連する事項を扱います。この節で扱うガイドラインは iPlanet^TM Application Server だけに当てはまるものではなく、Java アプリケーションのコーディング全般に当てはまる規則です。

• 直列化と直列化解除の回避

  Java でオブジェクトを直列化したり直列化を解除したりすると、CPU に負担がかかり、アプリケーションの速度が低下しがちになります。

• アレイの回避

  実行するのは難しいですが、Java ではアレイの使用は最小限にとどめてください。Java の主要目的の 1 つは安全性であり、C や C++ のプログラマを悩ませる問題の多くは、 Java で生じることはありません。Java のアレイは初期化されていることが保証され、その範囲外にアクセスすることはできません。

  範囲の検査には、実行時の索引検証と各アレイでわずかのメモリオーバーヘッドが必要です。最小限の時間しか使用しませんが、多数のアレイがコードで使用される場合はパフォーマンス低下の要因となります。

• StringBuffer.append() を使い、「+」演算子は使わない

  Java の文字列は不変です。つまり、一度作成すると変更できません。たとえば、次のシーケンスは、

  String str = "testing";

  str = str + "abc";

  コンパイラで解釈すると次のようになります。

  String str = "testing";

  StringBuffer tmp = new StringBuffer(str);

  tmp.append("abc");

  str = tmp.toString();

  このように、コピーは本質的に時間のかかる作業であり、多用するとパフォーマンスに影響を与える原因になります。StringBuffer.append() の使用をお勧めします。

• 遅延処理変数にnull 値を明示的に割り当てる

  これは、ガベージコレクタが安全に再生できるメモリ部分を簡単に識別するのに役立ちます。Java では、メモリを多量に使ったり、大量のメモリを循環させる (たとえば、多数のオブジェクトを作成して遅延処理をする) ことができます。参照を解放しないで、オブジェクトを保持したままでメモリリークさせることができます。これにより、ガベージコレクタはオブジェクトの再要求を中止し、その結果、使用されるメモリ量が増加します。このように、変数に null を設定して明示的に遅延処理することでパフォーマンスが向上します。

J2EE プログラミングのガイドライン

J2EE モデルにより、アプリケーション開発のフレームワークが定義されます。定義されるのは、アプリケーションアーキテクチャにおける JSP、Servlet、および EJB (JNDI、JMS、および JTS を含む) の使い方です。J2EE モデルの全部品にはそれぞれの使い方がありますが、アーキテクチャの設計にあたり、次の点に留意しておく必要があります。

• Servlet プログラミングのガイドライン

  iPlanet Application Server のアプリケーションはすべて JSP または Servlet (EJB へのエントリポイントでもある) によって提供されます。デフォルトモデルである Servlet マルチスレッドモデルの場合は、JVM ごとに Servlet のインスタンスが 1 つ作成されます。この JVM にある Servlet のリクエストはすべて同じ Servlet インスタンスを使います。これにより、スレッドの競合が発生することがあります。このため、クラス変数を使うと同期上の問題が起こるので、使わないようにします。

  また、コードやメソッドに対して同期句を使うとコードに危険な個所が作成されるので、使わないようにします。同期ブロックでは一度に 1 つのスレッドしか実行できません。残りのスレッドはブロックされ、アクセスできるようになるまで待機します。この待機キューは、高パフォーマンスの Web サイトにとってパフォーマンスを低下させる重大な要因となります。

• EJB 使用の回避

  EJB はサービスの再利用という点では非常に便利です。しかし、この柔軟性にはコストがかかります。これは、コンテナの実装における特性によるものではなく、EJB の動作を設計しているメソッドのためです。ここでは iPlanet Application Server がコンテナになります。J2EE アプリケーションでは、EJB への全リクエストがしばしば Servlet を経由します。

  Servlet は JNDI 検索を行い、Beans 参照を取得し、この参照を使って Beans メソッドを呼び出します。通常、参照はキャッシュされ、以後ヒットしたすべての場合に使われます。EJB にアクセスするには事前に実行する必要のある指示が多くあるので、EJB は同じタスクを実行する Servlet よりも本質的に時間がかかることがわかります。

  EJB を使う必要がある場合は、次の手順に従って応答時間を短くしてください。

  • EJB 参照を Servlet でキャッシュします。こうすると、リクエストごとに JNDI 検索を行う必要がなくなります。

  • 次に、EJB の種類をパフォーマンス順に示します。パフォーマンスがもっとも高い Beans タイプが最初になっています。
    • 状態のないセッション Beans

    • 状態のあるセッション Beans

    • CMP (コンテナ管理パーシスタンス) を持つエンティティ Beans

    • BMP (Beans 管理パーシスタンス) を持つエンティティ Beans

    EJB の中では状態のないセッション Beans がもっとも速く、パフォーマンスでは Servlet に匹敵します。

  • 状態のあるセッション Beans ではスティッキーロードバランスを使用します。スティッキーロードバランスを使用していない場合、セッションに格納されている Beans 参照がほかの iPlanet Application Server に転送されると、コンテナ間検索を行ってリクエストを処理する必要があります。これは非常に時間がかかります。

  • パフォーマンステストの結果に基づいてコンテナ (iPlanet Application Server) をサイジングします。プロセスのスレッドを作成し、iPlanet Application Server のタイムアウト値を設定します。EJB キャッシュを設定するとパフォーマンスが向上します。

  • Servlet と JSP を iPlanet Web Server ではなく iPlanet Application Server に配置します。次の場合はアプリケーションを iPlanet Application Server に配置します。
    • アプリケーションに高度なトランザクション機能がある

    • セッションデータを保護するためのフェールオーバーサポートが必要である

    • レガシーデータにアクセスする

  • アプリケーションの状態がほとんどなく、そのアプリケーションが読み取り専用であり、トランザクション型でない場合は、アプリケーションを iPlanet Web Server に配置します。

  • EJB をプレゼンテーションロジック (Servlet および JSP) とともに同じサーバ上に配置するようにサーバ管理者に依頼して、アプリケーション実行時のリモートプロシージャコール (RPC) の数を減らします。
    

    ---

    注	アプリケーションを中程度から多数の EJB に分割すると、アプリケーションパフォーマンスが著しく劣化し、オーバーヘッドが増加します。EJB は JavaBeans と同様、単なる Java オブジェクトではありません。EJB は Java オブジェクトよりも高レベルです。これらの EJB は、リモート呼び出しインターフェイスセマンティック、セキュリティセマンティック、トランザクションセマンティック、およびプロパティから構成されるコンポーネントです。

    ---