| JRun プログラマーガイド |
|
|
Web アプリケーションの最適化 |
|
| JRun プログラマーガイド |
|
|
Web アプリケーションの最適化 |
|
このセクションでは、Web アプリケーションに合わせて JRun の動作環境を改善する方法について説明します。
Cookie はサーバに保管され、クライアントとサーバ間でやり取りされるセッション ID で参照されます。Cookie はメモリに保管されるため、各セッションはシステムリソースを少し使用します。
次の表で、リソースの負荷を軽減するために変更できるセッション設定を説明します。
セッション設定の変更方法の詳細については、 「セッションの操作」 を参照してください。
ホットデプロイ機能は、コンポーネント構造に対する変更を検出すると、実行中の Web コンポーネントを自動的に再起動 (リデプロイ) します。
ホットデプロイが有効になっていると、JRun は、すべてのリソースの日付/タイムスタンプを定期的に確認して、ファイルが変更されたかどうかを調べます。この継続的なサイクルによってシステムリソースが少し使用されます。
ホットデプロイを無効にするには、次の属性を JRun のルートディレクトリ/servers/サーバ名/SERVER-INF/jrun.xml ファイル内の jrun.deployment.DeployerService サービスに追加します。
<attribute name="hotDeploy">false</attribute>
メモ： 運用サーバ上では、ホットデプロイを常に無効にする必要があります。
JRun と外部 Web サーバ間のコネクタの構成には、並行処理設定の最適化が含まれます。並行処理は、HTTP リクエストをプールし、分散する方法を定義します。これらの設定値を変更することによって、各 JRun サーバによって処理されるスレッドとリクエストの数を制限できます。実際に、その JRun サーバのトラフィックを調節できます。
たとえば、Web アプリケーションの平均レスポンス時間が RMI-CORBA データベースという 3 段階のトランザクションが原因で遅れるのであれば、新規リクエストを拒否せずにスループットを維持するために、より多くのリクエストを受け入れるようにキューを大きくする必要があります。この場合は、最大同時リクエスト数を予想されるリクエスト数よりも大きい値にします。最大同時リクエスト数の設定値は、リソースの安全弁の役割を果たします。
メモ： "同時リクエスト" と "同時ユーザー" の概念は異なります。1000 人の同時ユーザーをサポートする必要がある Web サイトでは、1000 人のユーザーがそれと同数のリクエストを一度に作成する可能性は小さいため、1000 個の同時リクエストをサポートする必要はありません。
次の表で、Web サーバへの接続に関する並行処理を設定できる設定値を説明します。
並行処理設定を変更するには、次の例のように新しい値を使用して、jrun.xml ファイル内の適切なサービスにプロパティを追加します。
<service class="jrun.servlet.http.WebService" name="WebService">
... <attribute name="minHandlerThreads">80</attribute> ... </service>
JRun Web サーバの設定を編集するには、WebService の属性を変更します。外部 Web サーバのコネクタ設定を編集するには、ProxyService の属性を変更します。
メモ： デフォルトの JRun 並行処理設定を変更する前に、トラフィックパターンが実際に監視できることを確認します。設定値を変更してしまうと、リソースを消耗する可能性があります。Web アプリケーションの負荷テストの詳細については、 「その他のリソース」 のリソースを参照してください。
オブジェクトを再利用してキャッシュすると、JVM ガーベッジコレクションおよびオブジェクト割り当てに関連するメモリと CPU サイクルを節約できます。オブジェクト割り当てには CPU サイクルとメモリが必要です。未リファレンスオブジェクトのガーベッジコレクションでは、ガーベッジコレクタのスレッドの実行中に JVM 内の他のすべてのスレッドを保留する必要があり、アプリケーションの処理速度が低下します。
選択した JVM により、Web アプリケーションのパフォーマンスに大幅な差が生じる可能性があります。Sun Microsystems の HotSpot Server VM および Appeal の JRockit では、世代間ガーベッジコレクションのような高度なアルゴリズムを使用しており、ガーベッジコレクションスレッドの実行時間が短縮されています。
さまざまな環境で負荷テストを実行して、どのオペレーティングシステムと JVM の組み合わせが特定の Web アプリケーションに最適かを調べる必要があります。
JVM のメモリ設定を変更すると、JRun サーバのパフォーマンスを向上させることができます。ただし、調整する前に、アプリケーションに必要なメモリの容量を知っておく必要があります。アプリケーションで負荷テストを行い、ヒープサイズを表示します。
JVM の最小 (または初期) ヒープサイズを、負荷テスト時に記録した最大値 (メモリ消費量) に設定します。また、最大ヒープサイズ値は、使用可能なメモリの合計から他の必要なリソースを引いた容量よりも小さい値に設定しますが、できるだけ最大の値を選択します。ご使用の JDK 内のデフォルト値 (通常は 128 MB) に最大ヒープサイズが設定されている場合に、その最大値を越えると、"OutOfMemory" エラーが発生する可能性があります。
最大ヒープサイズ値を設定するには、JMC の [JVM 設定] パネルの [最大ヒープサイズ (MB)] フィールドを編集します。[JVM 設定] パネルの [VM 引数] フィールドにコマンドライン引数を追加することによって他の設定を変更できます。
次の表で、設定可能な引数を説明します。これらの引数は、ご使用の JVM によって異なります。
| 引数 |
説明 |
| Java ヒープサイズの初期 (最小) 値 |
|
| Java ヒープサイズの最大値 |
|
| Java スレッドスタックサイズの値 |
パフォーマンスを最大限に高めるには、最大ヒープサイズと最小ヒープサイズを同じ値に設定します。それによって、JRun プロセスでヒープサイズを増やさずに済みます。
ログファイルは、デバッグや Web アプリケーションの利用状況の追跡には便利なツールですが、実質的なログファイルの生成に必要なオーバーヘッドが著しい場合があります。このような理由から、運用アプリケーションではロギングを無効にし、その代わりに Web サーバのログを情報源として使用することを検討してみてください。
JRun でロギングを無効にするには、次の例に示すように、/JRun のルートディレクトリ/servers/サーバ名/SERVER-INF/jrun.xml ファイルで LoggerService 属性を false に設定します。
...
<service class="jrunx.logger.LoggerService" name="LoggerService"> ... <attribute name="errorEnabled">false</attribute> <attribute name="warningEnabled">false</attribute> <attribute name="infoEnabled">false</attribute> <attribute name="debugEnabled">false</attribute> <attribute name="metricsEnabled">false</attribute> ... </service> ...
デフォルトでは、冗長なデータベースロギングは使用不可になっています。Web アプリケーションの開発中にこのロギングを有効にした場合、再び無効にするには、jrun-resources.xml ファイル内の適切なデータソースを編集し、デバッグ要素の値を false に設定します。
