前へ     目次     索引     DocHome     次へ     
iPlanet Application Server パフォーマンスおよびチューニングガイド



第 10 章   FAQ/よくある質問


iPlanetTM のシステムエンジニア、プロフェッショナルサービスコンサルタント、およびお客様は、長年にわたってさまざまな方法で iPlanet Application Server の運用環境を最適化してきました。この章はその結果をまとめて、複製したものです。

次の節では、パフォーマンス関連してよくある質問 (FAQ) を次のように分類しています。

今後もこの FAQ を充実させていくために、利用者からのフィードバックをお待ちしています。



環境設定


この節では、iPlanet Application Server 環境の設定に関する事項を扱います。

  1. 通常の運用環境では、iPlanet Application Server の CPU 1 個につき必要な RAM サイズはどのくらいですか。

    iPlanet Application Server の CPU 1 個につき 1 GB の RAM が必要です。

  2. Solaris での一般的な開発者サンドボックスインストールの場合は、1 つの開発チームに CPU は何個必要ですか。

    iPlanet Application Server では、CPU 1 個につき 3 〜 5 名の開発者をサポートできます。条件の厳しい使用法の場合は、CPU 1 個につき 2 〜 3 名になります。

  3. iPlanet Application Server をインストールするには、どのくらいのディスク容量が必要ですか。

    配布プログラムは約 150 MB ですが、インストールして操作するにはこの 3 倍の容量が必要です。最初は約 450 MB の未使用ディスク領域が必要です。インストール後の iPlanet Application Server の操作には約 256 MB のディスク容量が必要です。

  4. 1 つの iPlanet Application Server インスタンスを有効に活用するには何個のプロセッサが必要ですか。

    一般的に、iAS は 8 〜 12 個以内のプロセッサであれば実行することができます。1 つの iPlanet Application Server インスタンスには KXS が 1 つしかありませんが、KJS プロセスは多数存在させることができます。アプリケーションが KXS ではなく KJS で制約を受けているような場合は、12 プロセッサの範囲内で拡張することができます。ただし、分散セッション管理 (DSync) や Servlet の結果セットキャッシングのように、KXS ベースのサービスを頻繁に使う場合は、KXS のスケーラビリティはプロセッサ 8 個の範囲に制限されます。8 個から 12 個のプロセッサ範囲を超えて拡張するには、該当のマシンに複数の iPlanet Application Server インスタンスをインストールすることを検討してください。

  5. iPlanet Application Server の分散セッション管理 (DSync) 機能を使うと、オーバーヘッドが高くなる可能性があります。KXS プロセスで分散セッション管理 (DSync) の負荷を減らすには、インストール時にどのような点に注意すればよいでしょうか。

    DSync のバックアップを 1 つだけ行うようにします。こうするとマスタと同期されたバックアップの内部メモリセッションストアを保持するのに必要な DSync の作業量が減り、プライマリに障害が発生した場合に交代することができます。進行中のセッションの可用性を保証するには、DSync バックアップは 1 つで十分です。

  6. Java Servlet/JSP のプログラマですが、iPlanet Application Server のセッション管理機能をできるだけ効率的にするにはどうすればよいでしょうか。

    セッションの使い方を検討してください。KXS プロセスにある DSync 機能を使用すると、お使いの環境で負荷をかなり高めることになります。次の点を検討してみてください。

    • クラスタサイズを 4 インスタンスまでに制限します。このサイズを超えると、分散セッションストアを同期させるためのオーバーヘッドによってパフォーマンスが制限されることが多くなります。

    • スティッキーロードバランスを使います。セッション中、ユーザの後続の処理は必ず同じ KJS に戻り、セッション情報がローカルに利用できます。これは状態のあるセッション EJB では特に重要です。

  7. 管理者ですが、KXS ハンドルセッション管理の維持管理作業を効率的にするにはどうしたらよいでしょうか。

    セッションがタイムアウトや無効になった場合、メモリ内のセッションストアからすぐに削除する必要があります。セッション管理専用のスレッド数を増やすと、ほぼ同時に削除することができます。iPlanet Registry 内の次のプロパティを調整して、セッションノードの管理をより効率的に行います。

SOFTWARE/iPlanet/Application Server/6.0/Clusters/<machine-name>-NoDsync/SyncTimeoutThreadCount



システムのチューニング


  1. 上手にチューニングされた iPlanet Application Server システムの構成について教えてください。

    上手にチューニングされたシステムには次のような特徴があります。

    • すべてのサーバの CPU 時間が均一である

    • 各サーバのプロセッサの CPU 時間はすべて平均的に使用されている

    • すべての KJS プロセスで CPU 時間が同程度である

    • ワークフローが計算に集中するのはシステム時間の 0 〜 25% である

    • KXS プロセスに割り当てられたプロセッサがすべて活用されている

  2. マルチ CPU マシンに iPlanet Application Server を複数インストールしようと思います。これは最善の拡張方法でしょうか。

    1 台のマシンに複数の iPlanet Application Server をインストールするのは、ほかに方法がない場合だけにしてください。このようにすると、通常は運用管理が混乱します。代わりに、KJS (Java VM) プロセスを追加したり、iPlanet Application Server プロセスのスレッドプールで使用するスレッド数を変更したりして、まず iPlanet Application Server インスタンスを 1 つチューニングしてみてください。

  3. KXS プロセスに必要なスレッドはいくつですか。

    KXS ごとに 32 個のスレッドがデフォルトの設定です。ただし、このスレッド数を増やすことができます。しかし KXS のスレッド数を増やしても、パフォーマンスが著しく向上するとは限りません。

    上手にチューニングされたシステムには次のような特徴があります。

    • すべてのサーバの CPU 時間が均一である

    • 各サーバのプロセッサの CPU 時間はすべて平均的に使用されている

    • すべての KJS プロセスで CPU 時間が同程度である

    • ワークフローが計算に集中するのはシステム時間の 0 〜 25% である

    KXS プロセスプールに割り当てられたすべてのプロセッサが利用されることが重要です。KJS スレッドと比べ、KXS スレッドではあまり作業が行われません。このため、KXS スレッドは KJS ほど多く必要ありません。KXS のパフォーマンスを向上させたい場合は、プロセスまたはプロセッサのセットにバインド (pbind) してみてください。

  4. KJS とプロセッサのバインドは、いつ検討すればよいでしょうか。

    iPlanet Application Server のプロセスを特定のプロセッサやプロセッサセットとバインドすることは、特に Solaris 環境では大きなメリットがあります。マルチプロセッサマシンでは、常に KXS をプロセッサにバインドしてください。こうすると、マルチプロセッサの mutex ロックを使って関連付けたオーバーヘッドにより、スループットが大幅に向上します。

  5. KJS とプロセッサセット （複数プロセス） とのバインドは、いつ検討すればよいでしょうか。

    KXS がリクエストをキューに入れている場合は、プロセッサが 2 つあるプロセッサセットを作成します。KXS をこのプロセッサセットにバインドしてください。プロセッサが 3 つ以上あるプロセッサセットを KXS にバインドしても、通常、スループットは実質的に向上しません。

  6. KXS にバインドされているプロセスセットからプロセッサを外すのはどのような場合ですか。

    KXS がプロセッサを十分に活用しておらず、パワーが足りない KJS プロセスがある場合 (スレッドがキューに入っている場合)、KXS からプロセッサを外して KJS プロセスで新しく利用し、このプロセスを iPlanet Application Server に追加します。

  7. KJS に必要なスレッドはいくつですか。

    32 から始めて、プロセッサの負荷が高くなったら増やしてください。KJS に設定するスレッドプールは 48 までで十分です。これ以上になると、単にコンテキストの切り替えが増えるだけで、サイクルの無駄遣いになってしまいます。

  8. KJS とプロセッサのバインドは、いつ検討すればよいでしょうか。

    一般には、KJS とプロセッサまたはプロセッサセットはバインドしません。バインドしてもパフォーマンスは 5% も増えません。JDK 1.2.2 以降では、VM はマルチプロセッサ環境で十分動作するように最適化されています。

  9. KJS プロセスは Java VM の「ホーム」にあたりますが、 KJS が管理する JVM のヒープサイズなどはどのように変更すればよいですか。

    Solaris JDK で提供される引数は、iasenv.ksh シェルスクリプトの JAVA_ARGS シェル変数を介して設定することができます。JVM フラグ、特に -Xms と -Xmx フラグでは、各 KJS エンジンで使われる開始ヒープサイズと最大ヒープサイズを指定します。ヒープサイズは、システムで使用できるメモリに基づいて決定されます。できるだけ大きく設定して、同じサーバで動作しているほかのアプリケーションに不足が生じないようにします。開始ヒープサイズのデフォルトは 8 MB です。

    ヒープは必要に応じて自動的に大きくなります。開始時にヒープサイズを大きくしておくと、拡張中に頻繁にガベージ収集が行われることがありません。ヒープサイズの拡張に上限を設ける場合は、-Xmx フラグを設定します。フラグについての詳細は、JDK のマニュアルを参照してください。

  10. アプリケーションの動きが悪く、送信ボタンを押してからブラウザに結果が表示されるまで時間がかかります。どこで時間がかかるのかを知りたいのですが。

    リクエストプロセスサイクルのキーポイントに「クロック」を使ってみてください。

    • クロック 1 はクライアント (ブラウザや、LoadRunner などのロード生成ツール) でのタイムスタンプです。

    • クロック 2 は iWS Web サーバでのタイムスタンプで、フロントエンドスレッドがリクエストを受信する時刻です。

    • クロック 3 は iWS Web サーバでのタイムスタンプで、バックエンドのワーカースレッドがリクエストを受信する時刻です。

    • クロック 4 のタイムスタンプは、iPlanet Application Server Web コネクタがバックエンドワーカースレッドのリクエストに実際に応答する時刻です。

    • クロック 5 のタイムスタンプは、KXS がリクエストを受信する時刻です。リクエストは KJS に送信され、処理されます。

    • クロック 6 のタイムスタンプは、KJS から戻されたリクエストを KXS が受信する時刻です。

  11. クロック 1 とクロック 2 の間で時間がかかっている場合、原因は何でしょうか。

    この場合の遅れには、次のいずれかの理由が考えられます。

    • ネットワークが混んでいる

    • クライアント側の CPU や NIC がビジーである

    • Web サーバで TCP スタックがキューに入っている

    • ロードバランサやファイヤウォールなどの中間部でリクエストがキューに入っている

    • ロード生成クライアントの設定が間違っている

  12. クロック 2 とクロック 3 の間で 2 秒以上の遅延がある場合はどうでしょうか。

    バックエンドワーカースレッドがビジーで、リクエストがキューに入っていると考えられます。バックエンドのスレッド数を増やすか、フロントエンドのスレッド数を減らすことができます。

  13. クロック 3 とクロック 4 の間で 30 ミリ秒以上の遅延がある場合はどうでしょうか。

    あまりよい対策はありません。Web コネクタが予想した速度のパフォーマンスを出していないということです。残念ながら、この場合チューニングできることはありません。

  14. クロック 4 とクロック 5 の間で 3 秒以上の遅延がある場合はどうでしょうか。

    Web サーバの NIC でネットワークバッファリングが発生しているか、iPlanet Application Server の NIC でキューに入っている可能性があります。リソース不足のファイヤウォールも調べてみてください。通常のネットワークの混雑が原因の場合もあります。

  15. クロック 5 とクロック 6 のタイムスタンプが予想よりも遅い場合は何が原因ですか。

    KXS や KJS プロセスをチューニングする必要があります。KXS と KJS のスレッドプールを調べてください。また、KJS プロセスを追加することも検討してください。それ以外にも、iPlanet Application Server プロセスをプロセッサや、場合によってはプロセッサセットにバインドすることを考慮する必要があります。



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

  1. EJB プログラマですが、iPlanet Application Server の EJB コンテナのパフォーマンスを向上させるために何か調整することはありますか。

    • デフォルトの不活性化タイムアウトは 60 秒です。Beans インスタンスの作成速度が非常に遅く、Beans サイズが大きい場合は、この値を大きくします。不活性化プロセスが減少すると、パフォーマンスがやや向上することがあります。

    • メタデータキャッシュサイズを、アプリケーションに存在する Beans の種類の数にすることができます。デフォルトは 30 ですが、ホームが扱うすべてをキャッシュするには十分とは言えません。

    • Implementation Cache Size を、予想する同時ユーザセッション数に基づいて設定します。たとえば、200 の同時ユーザセッションがそれぞれ 1 つの状態を持つセッション EJB を必要とする場合、Implementation Cache Size を 200 以上に設定します。

  2. iPlanet Application Server のパフォーマンスを向上させるには、Java コード内で何をチェックしたらよいでしょうか。

    iPlanet Application Server の KJS プロセスには、Java コードを実行する J2EE コンテナが含まれています。KJS プロセスは独立した Java VM を管理します。そのため、VM ができるだけパフォーマンスを発揮できるようにするには、正しい Java ガイドラインに従う必要があります。次の点を調べてみてください。

    • 直列化や直列化解除を避ける。これは時間がかかる操作です。

    • アレイの多用を避ける。アレイを初期化したり、範囲外のアクセスを防ぐなど、Java がアレイに行う操作にはオーバーヘッドが発生するためです。

    • 変数に null を設定して明示的に参照を解除し、ガベージコレクションの効率を上げます。

    • Servlet クラスでクラス変数 (スタティックメンバ) を使わない。サーバでの同期化が必要になるためです。デフォルトでは、ユーザ全員が Web コンテナ (JVM) ごとに Servlet コードのコピーを 1 つ共有しています。

    • 同期されたメソッドや同期されたブロックをコードで使わない。

    • EJB の使用は慎重に行う。EJB はサーバに負荷をかけます。

  3. パフォーマンス上の理由から、アプリケーション内で EJB を慎重に使う必要がありますが、EJB の何が問題なのですか。

    EJB はすばらしいコンポーネントですが、サーバサイド Java のコンポーネントモデルです。また、コストがかかります。これはどのベンダの EJB サーバにも当てはまります。EJB にアクセスするには大量のオーバーヘッドが必要で、セキュリティやトランザクション管理など EJB コンテナが提供するサービスを管理するにもオーバーヘッドが必要です。このため、EJB を使う場合にはパフォーマンスの低下を最小限にするために、以下の点に注意してください。

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

    • スティッキーロードバランスを使い、セッション中の後続のリクエストが常に KJS (VM) と同じプロセスに戻るようにします。このようにすると EJB リソースはローカルになり、時間のかかる呼び出しをマシンを越えて行って EJB にアクセスすることが避けられます。

    • 状態のないセッション EJB を使います。パフォーマンスでは Servlet に匹敵します。

    • 状態を持つセッション Beans とエンティティ Beans は、状態のないセッション EJB Beans より時間がかかります。エンティティ EJB のパーシスタンス管理では BMP が CMP よりも時間がかかるために、エンティティ EJB のパフォーマンス集約度が最も高くなります。

  4. アプリケーションで Servlet HTML 結果キャッシュを使うと、パフォーマンスはどのくらい向上しますか。

    CPU 1 個の場合、Servlet キャッシュによりパフォーマンスはおよそ 2 倍になりますが、CPU が 2 個の iPlanet Application Server インスタンスでのテストではわずか 4% しか向上しませんでした。CPU が 4 個以上の場合もキャッシュによるパフォーマンスの向上はなかったので、Servlet 結果キャッシュの使用はお勧めしません。代わりに JSP 結果キャッシュを使ってください。

    JSP 結果キャッシュは KXS ベースではなく KJS ベースです。この方法でうまく拡張できるようにするために、iPlanet Application Server インスタンスごとに複数の KJS プロセスを設定することができます。

  5. どうすれば、もっとも効果的に Servlet HTML 結果キャッシュが行えますか。

    キャッシュを格納できるメモリを増やせば、キャッシュヒットの可能性を高めることができます。これは、Servlet キャッシュの配置記述子と JSP の Administration Tool で行います。

    HTML 結果キャッシュは Servlet の KXS で処理され、これはすでに過負荷になっていると思われる KXS にもう 1 つ作業をさせます。HTML 結果キャッシュを使うと確かにスループットが向上します。

  6. JSP によってキャッシュが起きます。

    このキャッシュは KJS で処理されます。KXS プロセスとは違い、iPlanet Application Server インスタンスごとに複数の KJS プロセスを設定することができます。したがって、KXS を使わないようにして JSP 結果キャッシュを使うことにより、結果キャッシュを効果的に稼動させることができます。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 3 月 6 日