Oracle9i Application Server for Windows NT Oracle HTTP Server powered by Apacheパフォーマンス・ガイド, リリース1.0.2

(1)

Oracle9i Application Server for Windows NT

Oracle HTTP Server powered by Apache

パフォーマンス・ガイド

リリース 1.0.2

2001年 2 月部品番号 : J02963-01

(2)

Oracle9i Application Server for Windows NT Oracle HTTP Server powered by Apache パフォーマンス・ ガイド, リリース 1.0.2

部品番号: J02963-01

原本名：Oracle9i Application Server Oracle HTTP Server powered by Apache Performance Guide Release 1.0.2 for Windows NT

原本部品番号：A86676-01

原本著者：Sharon Malek, Carol Orange, Leela Rao Copyright © 2000 Oracle Corporation. All rights reserved. Printed in Japan. 制限付権利の説明プログラムの使用、複製または開示は、オラクル社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権に関する法律により保護されています。当ソフトウェア（プログラム）のリバース・エンジニアリングは禁止されております。このドキュメントの情報は、予告なしに変更されることがあります。オラクル社は本ドキュメントの無謬性を保証しません。 * オラクル社とは、Oracle Corporation（米国オラクル）または日本オラクル株式会社（日本オラクル）を指します。危険な用途への使用についてオラクル社製品は、原子力、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションを用途として開発されておりません。オラクル社製品を上述のようなアプリケーションに使用することについての安全確保は、顧客各位の責任と費用により行ってください。万一かかる用途での使用によりクレームや損害が発生いたしましても、日本オラクル株式会社と開発元であるOracle Corporation（米国オラクル）およびその関連会社は一切責任を負いかねます。当プログラムを米国国防総省の米国政府機関に提供する際には、『Restricted Rights』と共に提供してください。この場合次の Legend が適用されます。

Restricted Rights Legend

Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication and disclosure of the Programs shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data -- General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

このドキュメントに記載されているその他の会社名および製品名は、あくまでその製品および会社を識別する目的にのみ使用されており、それぞれの所有者の商標または登録商標です。

(3)

はじめに

... v

1 パフォーマンスの概要

パフォーマンスの概要

パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語 ... 1-2 パフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとは ... 1-2 システム・スループット ... 1-4 待機時間 ... 1-4 重要なリソース ... 1-5 過度の需要による影響 ... 1-6 問題解決のための調整 ... 1-6 パフォーマンス目標の設定パフォーマンス目標の設定パフォーマンス目標の設定パフォーマンス目標の設定 ... 1-7 ユーザーの期待値の設定ユーザーの期待値の設定ユーザーの期待値の設定ユーザーの期待値の設定 ... 1-7 パフォーマンスの評価パフォーマンスの評価パフォーマンスの評価パフォーマンスの評価 ... 1-7 パフォーマンス管理の方法パフォーマンス管理の方法パフォーマンス管理の方法パフォーマンス管理の方法 ... 1-8 パフォーマンス改善の要因 ... 1-9 アーキテクチャアーキテクチャアーキテクチャアーキテクチャ ... 1-10

2 Web

サーバーのモニター

ネットワーク・アクティビティのモニターネットワーク・アクティビティのモニターネットワーク・アクティビティのモニターネットワーク・アクティビティのモニター ... 2-2 パフォーマンスパフォーマンスパフォーマンスパフォーマンス モニタによるパフォーマンス・データの収集モニタによるパフォーマンス・データの収集モニタによるパフォーマンス・データの収集モニタによるパフォーマンス・データの収集 ... 2-2 パフォーマンスモニタの起動 ... 2-3

(4)

mod_status ユーティリティを使用した Web サーバーのモニター ... 2-6 JServ プロセスのモニタープロセスのモニタープロセスのモニタープロセスのモニター ... 2-10

3 サイズ設定および構成

サイズ設定および構成

ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定ハードウェアおよびリソースのサイズ設定 ... 3-2 CPU 要件の決定要件の決定要件の決定要件の決定 ... 3-3 メモリー要件の決定メモリー要件の決定メモリー要件の決定メモリー要件の決定 ... 3-4 Oracle HTTP Server のメモリー要件の決定 ... 3-4 JServ のメモリー要件の決定 ... 3-4 Java のヒープ・サイズの決定 ... 3-4 サーブレットおよびOracleJSP のメモリー要件の決定 ... 3-5 CPU あたりの JServ プロセス数の決定 ... 3-6

4 HTTP

サーバーのパフォーマンスの最適化

ネットワークのチューニングネットワークのチューニングネットワークのチューニングネットワークのチューニング ... 4-2 ThreadsPerChild パラメータの設定パラメータの設定パラメータの設定パラメータの設定 ... 4-2 サーブレット・リクエストのThreadsPerChild の設定 ... 4-3 静的ページのリクエストのThreadsPerChild の設定 ... 4-3 SSL セッション・キャッシュを使用可能にするセッション・キャッシュを使用可能にするセッション・キャッシュを使用可能にする ... 4-3セッション・キャッシュを使用可能にするロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響について ... 4-4 HTTP/1.1 プロトコルの利点プロトコルの利点プロトコルの利点プロトコルの利点 ... 4-4 永続的な接続のサポート ... 4-4

5 Apache JServ

の最適化

JServ の概要の概要の概要の概要 ... 5-2 サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化 ... 5-3 サーブレット・クラスのロード ... 5-3 サーブレット・クラスの自動リロード ... 5-3 ロード・バランシングの実行方法 ... 5-4 シングル・スレッド・モデルのサーブレットの使用 ... 5-6 OracleJSP とはとはとはとは ... 5-7 OracleJSP のパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニング ... 5-8 セッション管理の影響 ... 5-8

(5)

OracleJSP のパフォーマンスのヒント ... 5-9

索引

(6)

(7)

はじめに

このマニュアルでは、Oracle HTTP Server powered by Apache の設定およびパフォーマンスのチューニングについて説明します。 Web サーバー、特に Apache の設定およびチューニングについては、多くの参考情報が存在します。このマニュアルでは、有用な場合にはそれらの参考情報について言及し、実際的であれば、それらの情報で説明されている設定を行った結果、どれ位パフォーマンスが向上するかについても触れます。オラクル社の社内テストで検証されていない推奨事項については、参考情報をそのまま使用し、その旨が明記されています。このマニュアルで説明されている社内テストは、再現性のあるテスト結果を得られるよう、すべて専用の100Mbps のネットワークで実行されました。ご使用の環境での結果は、ネットワーク設定や競合特性によって異なります。「はじめに」には、次のトピックが含まれます。 ■ 対象読者 ■ このマニュアルの編成 ■ マニュアルの表記規則

(8)

対象読者

このマニュアルは、Oracle HTTP Server powered by Apache の設定およびチューニングを担当するOracle9i Application Server の開発者およびシステム管理者を対象としています。 このマニュアルを使用するには、Web サーバーの管理、およびパフォーマンス・チューニングの概念に関する運用知識が必要です。

このマニュアルの編成

このマニュアルには、次の章が含まれています。第第第 第 1 章「章「章「章「パフォーマンスの概要パフォーマンスの概要パフォーマンスの概要パフォーマンスの概要」」」」パフォーマンスとチューニングの概念および用語について説明し、Oracle9i Application Server のアーキテクチャにおける Oracle HTTP Server のコンポーネントについても説明します。第第第 第 2 章「章「章「章「Web サーバーのモニターサーバーのモニターサーバーのモニターサーバーのモニター」」」」パフォーマンス・チューニングのためのモニターの重要性、およびWeb サーバーとオペレーティング・システム・ソフトウェアに関する情報収集のツールとプロセスについて説明します。第第第 第 3 章「章「章「章「サイズ設定および構成サイズ設定および構成サイズ設定および構成サイズ設定および構成」」」」パフォーマンス目標を達成するためのサイズ設定および構成に関するガイドラインおよび方法について説明します。第第第 第 4 章「章「章「章「HTTP サーバーのパフォーマンスの最適化サーバーのパフォーマンスの最適化サーバーのパフォーマンスの最適化」サーバーのパフォーマンスの最適化」」」 HTTP サーバーのパフォーマンスを改善するためのチューニング・パラメータと、キャッシュおよびロギングによるパフォーマンスへの影響について説明します。第第第 第 5 章「章「章「章「Apache JServ の最適化の最適化の最適化」の最適化」」」

Apache JServ のパフォーマンスとロード・バランシング、および OracleJSP のパフォーマンスの最適化について説明します。

(9)

マニュアルの表記規則

この項では、このマニュアルのテキストおよびコード例に使用されている表記規則について説明します。ここで説明する内容は、次のとおりです。 ■ テキストの表記規則 ■ コード例の表記規則

テキストの表記規則

特別な用語を識別しやすいように、テキスト内では様々な表記規則が使用されています。次の表で、これらの表記規則について説明し、その使用例を示します。

コード例の表記規則

コード例では、SQL、PL/SQL、SQL*Plus またはその他のコマンドライン構文が示されます。これらには、次の例のように、固定幅フォントが使用され、一般のテキストと区別して表示されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE'; 表記規則表記規則表記規則表記規則意味意味意味意味例例例例太字太字太字太字太字は、テキスト内で定義されている用語を示します。 ub4、sword または OCINumber などのC データ型が有効です。この句を指定することにより、索引構成表索引構成表索引構成表索引構成表が作成されます。イタリック体イタリック体文字は、構文またはプレース・ホルダを示します。 parallel_clauseを指定できます。 Uold_release.SQLを実行します。 old_releaseは、アップグレード前にインストール済みのリリースを示します。小文字の固定幅フォント小文字の固定幅フォントは、実行可能ファイルおよびユーザー定義要素のサンプルを示します。これらの要素には、コンピュータ名、データベース名、ネット・サービス名および接続識別子、さらにユーザー定義のデータベース・オブジェクトおよび構造体、列名、パッケージおよびクラス、ユーザー名およびロール、プログラムの単位およびパラメータ値が含まれます。 sqlplusと入力し、SQL*Plus を開きます。 department_id、department_name および location_id列は、hr.departments 表内に存在します。 QUERY_REWRITE_ENABLED初期化パラメータを trueに設定します。 oeユーザーで接続します。

(10)

表記規則表記規則表記規則表記規則意味意味意味意味例例例例 [ ] 大カッコ内には、1 つ以上のオプションの項目が含まれます。大カッコは入力しないでください。

DECIMAL (digits [ , precision ])

{ } 中カッコ内には2 つ以上の項目が含まれ、そのうちの1 つが必須であることを示します。中カッコは入力しないでください。 {ENABLE | DISABLE} | 縦線は、大カッコまたは中カッコ内の選択肢を示します。これらのオプションのうちの1 つを入力します。縦線は入力しないでください。 {ENABLE | DISABLE} [COMPRESS | NOCOMPRESS] ... 横方向の省略記号は、次のいずれかを示します。 ■ コード中で例に直接関係のない部分が省略されている。 ■ コードの一部が繰返し可能である。

CREATE TABLE ...AS subquery;

SELECT col1, col2, ..., coln FROM employees; . . . 縦方向の省略記号は、コード中で、例に直接関係のない行が何行か省略されていることを示します。その他の表記大カッコ、中カッコ、縦線および省略記号以外の記号は、表示されているとおりに入力する必要があります。 acctbal NUMBER(11,2);

acct CONSTANT NUMBER(4) := 3;

イタリック体イタリック体のテキストは、特定の値を指定する必要のある変数を示します。 CONNECT SYSTEM/system_password 大文字大文字で表記されている部分は、システムで定義されている要素を示します。ユーザーが定義する用語と区別するために、これらの用語は大文字で表記されます。用語が大カッコで囲まれている場合を除いて、表示されている順序およびスペルのとおりに入力します。ただし、これらの用語には大文字・小文字の区別がないため、小文字で入力しても構いません。

SELECT last_name, employee_id FROM employees;

SELECT * FROM USER_TABLES; DROP TABLE hr.employees;

小文字小文字で表記されている部分は、ユーザーが指定するプログラム要素を示します。たとえば、小文字は表、列またはファイルの名前を示します。

SELECT last_name, employee_id FROM employees;

(11)

1

パフォーマンスの概要

この章では、パフォーマンスとチューニングの概念について説明し、Oracle9i Application Server のアーキテクチャについて簡単に説明します。この章には、次の項が含まれています。 ■ パフォーマンスに関する用語 ■ パフォーマンスのチューニングとは ■ パフォーマンス目標の設定 ■ ユーザーの期待値の設定 ■ パフォーマンスの評価 ■ パフォーマンス管理の方法 ■ アーキテクチャ

(12)

パフォーマンスに関する用語

次に、このマニュアルで使用されているパフォーマンスに関する用語を示します。

パフォーマンスのチューニングとは

パフォーマンスは、事前に設定しておく必要があります。アプリケーションの分析および設計中にパフォーマンス要件を予測し、最適なパフォーマンスのコストと利益を考慮する必要があります。この項では、次のような基本概念について説明します。 ■ 応答時間 ■ システム・スループット同時実行性同時実行性同時実行性同時実行性複数のリクエストを同時に処理する能力。同時実行性メカニズムの例には、スレッドおよびプロセスがあります。競合競合競合競合リソースの競合。ハッシュハッシュハッシュハッシュアルゴリズムを使用してテキスト文字列から生成された数値。通常、ハッシュ値はテキストに比べてかなり小さくなります。ハッシュ数値は、セキュリティ、およびデータへの高速なアクセスの目的で使用されます。レイテンシレイテンシレイテンシレイテンシ全体のタスクを完了するために、あるシステム・コンポーネントが別のコンポーネントを待機している時間。レイテンシは、無駄な時間として定義できます。ネットワークのコンテキストでは、レイテンシはパケットのソースから宛先への移動時間として定義されます。応答時間応答時間応答時間応答時間リクエストの送信から応答の受信までの時間。スケーラビリティスケーラビリティスケーラビリティスケーラビリティ使用可能なハードウェア・リソースに比例して、そして使用可能なハードウェア・リソースによってのみ制限された状態でシステムがスループットスループットスループットを提供できる能力。スループットスケーラブルなシステムとは、応答時間およびスループットスループットスループットスループットに悪影響を与えずに、増加したリクエストの処理が可能なシステムです。サービス時間サービス時間サービス時間サービス時間リクエストの受信からリクエストへの応答完了までの時間。思考時間思考時間思考時間思考時間ユーザーが実際にプロセッサを使用していない時間。スループットスループットスループットスループット単位時間あたりに処理されるリクエスト数。待機時間待機時間待機時間待機時間リクエストの送信からリクエストの開始までの時間。

(13)

パフォーマンスのチューニングとは ■ 過度の需要による影響 ■ 問題解決のための調整 ■ 応答時間応答時間応答時間応答時間応答時間はサービス時間サービス時間サービス時間サービス時間と待機時間待機時間待機時間の合計であるため、次の方法でパフォーマンスを向上で待機時間きます。 ■ 待機時間待機時間を削減する待機時間待機時間 ■ サービス時間サービス時間を削減するサービス時間サービス時間図1-1に、1 つのリソースに対して 10 個のタスクが競合している状態を示します。図図図 図 1-1 個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理関連項目関連項目関連項目 関連項目 : パフォーマンス要件、およびシステムのどの部分をチューニングするかを判別する方法については、1-7 ページの「パフォーマンス目標の設定」を参照してください。 1 2 3 4 5 6 7 8 9 10

(14)

パフォーマンスのチューニングとは複数のリソースを使用したパラレル処理の場合、より多くのリソースをタスクに割り当てることができます。各タスクは専用のリソースを使用してすぐに実行されるため、待機時間待機時間待機時間が待機時間発生しません。

システム・スループット

システム・スループットスループットスループットスループットは、一定時間内に完了する処理量です。スループットスループットスループットは、次の方法スループットで増加できます。 ■ サービス時間サービス時間を削減する。サービス時間サービス時間 ■ 不足しているリソースを増加することにより、全体の応答時間応答時間応答時間を削減する。たとえば、応答時間システムのボトルネックがCPU である場合には、CPU を追加できます。

待機時間

1 つのタスクのサービス時間サービス時間サービス時間が同じ場合でも、競合サービス時間競合競合が増加すると待機時間競合待機時間待機時間は長くなります。待機時間 1 秒を要するサービスを多数のユーザーが待っている場合、10 番目のユーザーは 9 秒間待機する必要があります。図1-2に、待機時間待機時間待機時間待機時間とリソースに対する競合競合競合の関係を示します。競合図図図 図 1-2 リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加リソースに対する競合の増加による待機時間の増加

(15)

パフォーマンスのチューニングとは

重要なリソース

CPU、メモリー、I/O 容量およびネットワーク帯域幅などのリソースは、サービス時間サービス時間サービス時間サービス時間短縮の鍵となります。リソースを増加すると、スループットスループットスループットが増加し、応答時間スループット応答時間応答時間応答時間も短縮できます。パフォーマンスは次の要因に依存します。 ■ 使用可能なリソースの量 ■ リソースを必要とするクライアントの数 ■ リソースに対するクライアントの待機時間 ■ クライアントがリソースを保持する時間図1-3に、リクエスト単位数が増加すると、サービスの完了までに要する時間も増加することを示します。図図図 図 1-3 サービス完了までの時間と需用率サービス完了までの時間と需用率サービス完了までの時間と需用率サービス完了までの時間と需用率この状況を解消するには、2 つの方法があります。 ■ 許容範囲の応答時間応答時間応答時間応答時間を維持するために需用率を制限する ■ リソースを追加する

(16)

パフォーマンスのチューニングとは

過度の需要による影響

過度の需要により、応答時間応答時間応答時間応答時間が増加し、スループットスループットスループットが減少します。この様子をスループット図1-4に示します。需用率がスループットスループットスループットスループットの限度を超過する可能性がある場合、調整を要するパラメータ（たとえば、Oracle HTTP Server の ThreadsPerChild および JServ の

security.maxConnections）を判別し、設定を変更します。図図図 図 1-4 需要の増加とスループットの減少需要の増加とスループットの減少需要の増加とスループットの減少需要の増加とスループットの減少

問題解決のための調整

パフォーマンスに関する問題は、次のような調整により解決できます。単位消費リクエストあたりのリソース（CPU、メモリー）の消費の削減により、パフォーマンスを改善できます。これは、プーリングおよびキャッシングにより実現できます。機能面での需要問題によっては、処理のスケジュールを変更したり、処理を分散しなおすことによって解決できます。容量リソース（CPU など）の増加や再割当てによって問題を解決できる場合があります。

(17)

パフォーマンスの評価

パフォーマンス目標の設定

システムを設計する場合もメンテナンスを行う場合も、最適化の手段および対象を判断できるよう、具体的なパフォーマンス目標を設定する必要があります。特定の目標を持たずにパラメータを変更すると、目立った効果もなくシステムのチューニングに余分な時間を費やすことになります。具体的なパフォーマンス目標の例として、注文入力の応答時間応答時間応答時間を応答時間 3 秒以内にする、などがあります。アプリケーションがその目標を達成できない場合、原因（たとえば I/O 競合競合競合競合など）を識別して対処します。開発中にアプリケーションをテストして、設計時に設定されたパフォーマンス目標を達成できるかどうかを調べます。通常、チューニングには他の面とのトレード・オフが発生します。ボトルネックを判断できたら、目標を達成するために、他の部分のパフォーマンスを変更する必要がある場合もあります。たとえば、I/O が問題である場合、メモリーまたはディスクの購入が必要な場合があります。購入できない場合は、目標のパフォーマンスを得るためにシステムの同時実行性同時実行性同時実行性を同時実行性制限する必要があります。ただし、パフォーマンスの目標が明確に定まっていれば、何が最も重要かがわかっているため、パフォーマンス向上のために何を犠牲にするかの判断が容易になります。

ユーザーの期待値の設定

アプリケーション開発者、データベース管理者およびシステム管理者は、ユーザーが期待しているパフォーマンスを、注意しながら適切に設定する必要があります。システムが特に複雑な処理を行っている場合は、単純な処理を行っている場合よりも応答時間応答時間応答時間が長くなる可能応答時間性があります。どの処理に時間がかかるかを明確にユーザーに知らせる必要があります。

パフォーマンスの評価

パフォーマンス目標を明確に定めると、パフォーマンスのチューニングが成功したかどうか、容易に判断できます。チューニングの成功を左右するのは、ユーザー・コミュニティに対して設定した機能面での目標、基準が満たされたかどうかを判断する能力、そして例外事項を解決するための対策を講じる能力です。常にパフォーマンスをモニターすることにより、十分にチューニングされたシステムを維持できます。アプリケーションのパフォーマンスの履歴を記録することにより、有効な比較が可能となります。様々な大きさの負荷に関する実際のリソース消費データを使用して、客観的なスケーラビリティスケーラビリティスケーラビリティの調査を行うことにより、予期される負荷のボリュームに合わせたリスケーラビリティソース要件を予測できます。

(18)

パフォーマンス管理の方法

システムの最適効率を実現するためには、計画、モニターおよび定期的な調整が必要です。パフォーマンス・チューニングの最初のステップは、目標を決定し、使用可能なテクノロジを効率的にアプリケーションに使用するよう設計することです。システムのインプリメント後には、システムを定期的にモニターし、調整する必要があります。たとえば、90% のユーザーの応答時間応答時間応答時間応答時間を5 秒以下にし、すべてのユーザーの最長応答時間応答時間応答時間を応答時間 20 秒にするように保証するとします。通常、これは簡単なことではありません。アプリケーションには、それぞれ特徴および許容できる応答時間が異なる様々な処理が含まれます。それぞれのアプリケーションに対し、適切な目標を設定する必要があります。また、負荷の変動も判別する必要があります。たとえば、図1-5に示すように、ユーザーはシステムに午前9 時から 10 時に集中的にアクセスし、再び午後 1 時から 2 時に集中的にアクセスする可能性があります。たとえば、毎日あるいは毎週など、定期的に負荷のピークが発生する場合、一般的には負荷のピーク時の要件に合わせてシステムを設定し、チューニングします。ピーク時以外にアプリケーションにアクセスするユーザーは、ピーク時のユーザーよりも短い応答時間応答時間応答時間応答時間を得られます。負荷のピークが頻繁に発生しない場合は、少ないハードウェア構成でコストを抑えるために、負荷のピーク時には応答時間応答時間応答時間応答時間が長くても我慢することも考えられます。図図図 図 1-5 容量と機能面での需要の調整容量と機能面での需要の調整容量と機能面での需要の調整容量と機能面での需要の調整

(19)

パフォーマンス管理の方法

パフォーマンス改善の要因

パフォーマンスは、様々な領域にまたがっています。 ■ アプリケーション設計: ハードウェア・リソースを効率的に利用し、ユーザーの増加に効率的に対処するアプリケーションの設計。 ■ サイズ設定と構成: パフォーマンス目標をサポートするために必要なハードウェアのタイプの判断。第3 章「サイズ設定および構成」を参照してください。 ■ パラメータのチューニング: アプリケーションの最高のパフォーマンスを得るための、設定可能なパラメータの設定。第4 章「HTTP サーバーのパフォーマンスの最適化」および第5 章「Apache JServ の最適化」を参照してください。 ■ パフォーマンスのモニター: アプリケーションが使用しているハードウェア・リソースおよびユーザーが費やしている応答時間応答時間応答時間の判断。応答時間第2 章「Web サーバーのモニター」を参照してください。 ■ トラブルシューティング: アプリケーションが過度にハードウェア・リソースを使用していたり、応答時間応答時間応答時間応答時間が目標よりも長い場合の理由の診断。関連項目関連項目関連項目 関連項目 : ■ サイズ設定および構成の詳細は、第3 章「サイズ設定および構成」を参照してください。 ■ パラメータのチューニングの詳細は、第4 章「HTTP サーバーのパフォーマンスの最適化」および第5 章「Apache JServ の最適化」を参照してください。 ■ パフォーマンスのモニターの詳細は、第2 章「Web サーバーのモニター」を参照してください。

(20)

アーキテクチャ

図1-6に、Oracle9i Application Server のアーキテクチャを示します。

このマニュアルでは、次のコンポーネントのパフォーマンスと設定について説明します。

■ Oracle HTTP Server powered by Apache ■ Apache JServ

■ OracleJSP

図図図

(21)

2

Web

サーバーのモニター

この章では、ご使用のシステムに関するパフォーマンス情報の収集方法について説明します。この情報は、リソースを最大限に活用するために役立ちます。この章には、次の項が含まれています。 ■ ネットワーク・アクティビティのモニター ■ パフォーマンスモニタによるパフォーマンス・データの収集 ■ Web サーバーのモニター ■ JServ プロセスのモニター

(22)

ネットワーク・アクティビティのモニター

Network Monitor を使用して、ネットワーク・トラフィックをモニターすることが可能です。 Network Monitor を Windows NT サーバーにインストールし、Network Monitor Agent をモニター対象のワークステーション（クライアント）にインストールする必要がありま

す。 Network Monitor により、2 台のコンピュータ間で送信されるネットワーク・パケット

の追跡および分析が行われます。

Network Monitor のインストール方法および使用方法は、マイクロソフト社の Web サイトを参照してください。

パフォーマンス

パフォーマンスモニタによるパフォーマンス・データの収集

モニタによるパフォーマンス・データの収集

パフォーマンスモニタは、Windows のユーティリティで、オペレーティング・システムおよびOracle HTTP Server に関するパフォーマンス統計を収集します。次の場合に使用可能です。 ■ リソース使用率の判別 ■ パフォーマンスのボトルネックの識別 ■ 現在のアクティビティの統計またはログ・ファイルの表示 ■ パフォーマンスに関する設定変更の影響の観察パフォーマンスモニタは、少量のシステム・リソースを消費します。消費量は、収集データの頻度、サイズおよび場所によって異なります。パフォーマンスモニタは、平均で 2 ∼ 5MB のメモリーおよび1 ∼ 5% の CPU タイムを使用します。物理ディスク、論理ディスクおよびメモリーなど、モニター可能なコンポーネントは、パフォーマンスモニタではオブジェクトオブジェクトオブジェクトオブジェクトと呼ばれます。各オブジェクトオブジェクトオブジェクトオブジェクトごとに、そのオブジェオブジェオブジェオブジェクトクトクトクト専用のパフォーマンス・インジケータであるカウンタカウンタカウンタ・セットが存在します。カウンタたとえば、 HTTP サーバーまたは Java プロセスをモニターするには、モニター対象の Process オブジェオブジェオブジェオブジェクトクトクト

クトおよびカウンタカウンタカウンタカウンタを選択します。カウンタには、% Processor Time、% User Time、 Page Faults/secおよび Working Set などがあります。

モニター対象のオブジェクトの数および組合せは、任意に設定可能です。すべてのシステムに、次のオブジェクトが用意されています。 ■ System ■ Memory ■ Cache ■ PhysicalDisk

(23)

パフォーマンスモニタによるパフォーマンス・データの収集 ■ Process ■ Thread ■ Server ■ Processor ■ Browser および Server などのネットワーク・オブジェクトオブジェクトオブジェクトオブジェクト

パフォーマンス

パフォーマンスモニタの起動

モニタの起動

パフォーマンスパフォーマンスパフォーマンスパフォーマンス モニタ・ユーティリティを起動するには、次のステップを実行します。モニタ・ユーティリティを起動するには、次のステップを実行します。モニタ・ユーティリティを起動するには、次のステップを実行します。モニタ・ユーティリティを起動するには、次のステップを実行します。 1. 「スタート」メニューから、「プログラム」を選択します。 2. 「管理ツール」メニューから、「パフォーマンスモニタ」を選択します。「パフォーマンスモニタ」ウィンドウが開きます。

プロセス・アクティビティのグラフの作成

パフォーマンスモニタのグラフ・ビューでは、パフォーマンスのカウンタ値がリアルタイムで横長のグラフに表示されます。プロセス・アクティビティのグラフを作成するには、次のステップを実行します。プロセス・アクティビティのグラフを作成するには、次のステップを実行します。プロセス・アクティビティのグラフを作成するには、次のステップを実行します。プロセス・アクティビティのグラフを作成するには、次のステップを実行します。 1. 「表示」メニューから、「グラフ」を選択します。 2. 「編集」メニューから、「グラフに追加」を選択します。「グラフに追加」ダイアログ・ボックスが開きます。 3. モニターするコンピュータのホスト名を「コンピュータ」フィールドに入力するか、または選択します。（デフォルトは、ローカルのコンピュータです。） 4. 「オブジェクト」ドロップダウン・リストで、「Process」を選択します。 5. 「インスタンス」リストで、プロセスプロセスプロセスプロセスを選択します。（HTTP サーバーをモニターするには、2 番目の Apache プロセスを選択します。これは子プロセスで、リクエスト処理を行うスレッドが含まれています）。 6. 「カウンタ」リストで、使用するカウンタカウンタカウンタカウンタを選択します。（複数のカウンタカウンタカウンタカウンタを選択するには、[Ctrl] キーを押しながらカウンタ名を選択します。） 7. 「追加」をクリックします。

(24)

パフォーマンスモニタによるパフォーマンス・データの収集図図図 図 2-1 パフォーマンスパフォーマンスパフォーマンスパフォーマンスモニタのグラフ・ビューモニタのグラフ・ビューモニタのグラフ・ビューモニタのグラフ・ビュー

パフォーマンス統計のロギング

パフォーマンス統計は、グラフ・ビューではリアルタイムで表示されますが、ロギングを使用して統計をログ・ファイルに保存することも可能です。ロギングを使用可能にするには、次のステップを実行します。ロギングを使用可能にするには、次のステップを実行します。ロギングを使用可能にするには、次のステップを実行します。ロギングを使用可能にするには、次のステップを実行します。 1. 「表示」メニューから、「ログ」を選択します。 2. 「編集」メニューから、「ログに追加」を選択します。「ログに追加」ダイアログ・ボックスが開きます。 3. モニターするコンピュータのホスト名を「コンピュータ」フィールドに入力するか、または選択します。 4. モニターするオブジェクトを選択します。（複数のオブジェクトを選択するには、[Ctrl] キーを押しながらオブジェクト名を選択します。） 5. 「追加」をクリックします。 6. 「完了」をクリックします。 7. 「オプション」メニューから、「ログ」を選択します。

(25)

パフォーマンスモニタによるパフォーマンス・データの収集 10.「ログの開始」をクリックします。

ログ・ファイル・データのレポートまたはグラフの作成

ログに記録されたパフォーマンス・データを、グラフまたはレポートの形式で表示可能です。これを行うには、パフォーマンスモニタが実行されており、ログ・ファイルの状態が「収集中」になっている必要があります（ログ・ファイルにアクセスする前に、ログを停止する必要があります）。以前のロギング・セッションで保存したログ・ファイルからレポートまたはグラフを作成する場合、ステップ3 から開始してください。ログ・ファイルからデータを選択するには、次のステップを実行します。ログ・ファイルからデータを選択するには、次のステップを実行します。ログ・ファイルからデータを選択するには、次のステップを実行します。ログ・ファイルからデータを選択するには、次のステップを実行します。 1. 「オプション」メニューから、「ログ」を選択します。 2. 「ログの停止」をクリックします。ウィンドウの表示領域が消去され、状態が「停止」に変わります。 3. 「表示」メニューから、「グラフ」または「レポート」を選択します。 4. 「オプション」メニューから、「データ」を選択します。「データ」ダイアログ・ボックスが表示されます。 5. 「ログファイル」ラジオ・ボタンをクリックし、ログ・ファイルを選択するために、参照ボタンをクリックします。「入力ログファイルを開く」ダイアログ・ボックスが開きます。 6. ファイルを選択し、「開く」をクリックします。 7. 「OK」をクリックします。 8. 「編集」メニューから、「時間ウィンドウ」を選択します。「入力ログファイルの時間枠」ダイアログ・ボックスが開きます。 9. 使用する時間間隔の開始および停止時間を、ブックマークまたはスクロール・バーを使注意注意注意 注意 : パフォーマンスモニタのログ・ファイルは急速に大きくなるため、ファイル・サイズに注意し、大きくなりすぎる前に別のログ・ファイルに変更してください。パフォーマンスモニタには、ファイル・サイズを監視するメカニズムが存在しません。

(26)

Webサーバーのモニター 12.「追加」をクリックします。 13.「完了」をクリックします。選択した期間のデータがグラフまたはレポートに表示されます。

Web

サーバーのモニター

パフォーマンスのチューニングには、システム・アクティビティのモニターが不可欠です。 Oracle HTTP Server では、mod_status モジュールを使用して、現在のサーバー統計を含

め、サーバー側のステータス情報が提供されます。これらのサーバー・ステータス・レポー

トを取得するには、次の各項で説明するようにWeb サーバーを設定する必要があります。

mod_status

ユーティリティを使用した

ユーティリティを使用した Web

Web

サーバーのモニター

モニターを使用可能にするには、httpd.conf ファイルを編集して、your_domain.com を、モニターするコンピュータのホスト名に置き換えます。

<Location /server-status> SetHandler server-status Order deny, allow Deny from all

Allow from your_domain.com </Location> 最大限の情報が表示されるように、ExtendedStatus ディレクティブが On に設定されていることを確認します。 your_domain.comのみでなく、すべてのドメインからのアクセスを許可すると、ドメイン外のマシンからご使用のサーバーをモニターすることが可能です。ただし、ご使用のサーバー・ステータスにあらゆるサイトからアクセス可能であるため、セキュリティ面で問題があることを認識する必要があります。システム・モニターに使用するドメインのみ指定することをお薦めします。 モニターを使用可能にすると、http://hostname:port/server-status で現在の統計 を表示できます。hostname:port は、モニターするホスト名およびポートです。これらの 統計により、ご使用のシステムの混雑状況を知ることができます。次の内容が表示されます。 ■ 表示中のステータスのホスト名 ■ サーバーのバージョン ■ サーバーが構築された日付

(27)

Webサーバーのモニター

■ アイドル状態のサーバー数

■ 現在のサーバーの状態（たとえば、接続待機中、リクエストの読込み中、応答の送信中

(28)

Webサーバーのモニター図2-2に、ExtendedStatus がオンになっているサーバー・ステータス・ページのスナップショットを示します。図図図 図 2-2 サーバー・ステータス・ページサーバー・ステータス・ページサーバー・ステータス・ページサーバー・ステータス・ページ

(29)

Webサーバーのモニター

サーバー・ステータス情報の解析

画面（ExtendedStatus を使用可能にした状態）には、1 つのサーバーが応答を送信中であることが示されています。 ThreadsPerChild は 50 に設定されているため、アイドル状態のサーバーは49 あります（使用中のサーバーは、サーバー・ステータス・リクエストに応答中のサーバーです）。 M（モード列）の値から、サーバーが処理のどの段階にあるかを判断できます。

サーバー・ステータス表示のカスタマイズ

図2-2に、ある瞬間のサーバーのスナップショットを示します。サーバー・ステータスURL にrefresh パラメータを含めると、任意の間隔でサーバー統計を更新して表示できます。 http://servername:port/server-status?refresh=x servername:portは、モニターしているサーバーおよびポート番号で、x は、データ更新までの秒数を示す整数です。たとえば、統計を3 秒ごとに更新するには、refresh=3 と指定します。また、統計をデータ分析プログラムまたはスプレッドシート・プログラムで処理できるよう、統計をマシンで読込み可能な形式で表示すると便利な場合があります。これを行うには、次に示すように、URL の最後に auto を追加します。 http://servername:port/server-status?auto 図図図 図 2-3 サーバー統計表示サーバー統計表示サーバー統計表示サーバー統計表示

(30)

JServプロセスのモニター

JServ

プロセスのモニター

Oracle9i Application Server の開始後、すべての JServ プロセスが正しく開始されているかど

うかを確認できます。処理中にパフォーマンスが低下した場合、「Status」列を参照すると、その原因がJServ プロセスの停止によるものかどうかがすぐに判断できます（設定済みの各プロセスのステータスは、Up または Down のいずれかです）。 1. jserv.confファイルのJServ ステータス・ハンドラ・セクションのコメントを削除してモニターを使用可能にし、JServ のステータスにアクセスするホストを指定します（デフォルトは localhost です）。ご使用のシステムのステータス情報にアクセス可能なホストを選択する際、必ずセキュリティ面を考慮してください。 <Location /jserv/> SetHandler jserv-status

order deny, allow deny from all

allow from hostname_1.com allow from hostname_2.com </Location>

2. 次のようにブラウザに入力します。

http://hostname:port/jserv/

port には、Web サーバーがリスニングを行うポートを指定する必要があります

（httpd.conf ファイル内に存在します）。「Configured Hosts」列にホストのリンクが

表示されます。

3. モニターするホストをクリックします。

(31)

JServプロセスのモニター

図図図

(32)

JServプロセスのモニター Upまたは Down という単語の後のカッコ内に表示される記号には、次のような意味があります。注意注意注意 注意 : JServ ステータス・モニターには、jserv.conf ファイルで設定されているJServ プロセスがすべて表示されますが、すべてが開始されているとは限りません。また、いずれかが停止している可能性もあります。たとえば、図2-4には4 つの JServ プロセスが示されており、ステータスはすべて Up です。 1 つ以上のステータスが Down の場合も、4 つとも表示されます。注意注意注意 注意 : 「Status」列の値は、手動モードで開始されたプロセスについての み表示されます。自動モードで開始されたシングル・プロセスについては、値は表示されません。記号記号記号記号意味意味意味意味 + プロセスは実行中です。 - _{プロセスは停止中です。} X _{プロセスは即時停止されました（プロセスの終了前に既存の} リクエストは処理されませんでした）。 / _{プロセスは既存リクエストの実行を待って停止されました} （プロセスの終了前に既存のリクエストは処理されました）。

(33)

3

サイズ設定および構成

この章では、パフォーマンス目標を達成する際に役立つ、サイズやその他の設定に関するガイドラインを示します。また、CPU および消費メモリーなどのパフォーマンス要因についても説明します。この章には、次の項が含まれています。 ■ ハードウェアおよびリソースのサイズ設定 ■ 同時ユーザーおよびユーザー数について ■ CPU 要件の決定 ■ メモリー要件の決定

(34)

ハードウェアおよびリソースのサイズ設定

ハードウェア・リソースは、インストールの最小推奨事項に加えて、使用するアプリケーションの要件を満たしている必要があります。ハードウェアに関連するパフォーマンスのボトルネックを避けるには、各ハードウェア・コンポーネントを容量の80% 以下で操作してください。特に、プロセッサとメモリー・リソースは、予期される最大のユーザー負荷に対して多めに割り当てる必要があります。

同時ユーザーおよびユーザー数について

必要なハードウェア・リソースの量は、アプリケーションによって異なります。ユーザーの思考時間思考時間思考時間思考時間やネットワークのレイテンシを考慮に入れずにリソースを推定するという誤りがよく見受けられます。アプリケーションのサイズを決定する際、予想ユーザー数と実際の同時ユーザー数との関係について把握している必要があります。これは、思考時間思考時間思考時間とアプリケー思考時間ションの平均応答時間応答時間応答時間から判断します。応答時間必要なメモリー量を判断する際、同時実行ユーザー数（ユーザー数の合計ではない）にユーザーあたりのコストを掛けた数値も考慮する必要があります。注意注意注意 注意 : httpd.confファイルの ThreadsPerChild 設定により、同時実行ユーザー数が制限されます。

(35)

CPU要件の決定表3-1に、思考時間思考時間思考時間とサービス時間思考時間サービス時間サービス時間サービス時間が同時実行性同時実行性同時実行性に与える影響と、その結果生じるシステム同時実行性のパフォーマンスの例を示します。

CPU

要件の決定

ほとんどのアプリケーションの場合、CPU 使用率の大部分はアプリケーションのコード処理によるものです。表3-2に示すように、アプリケーションのCPU 要件は、アプリケーションの複雑さと作業負荷によって異なります。開発サイクル全体を通じて、アプリケーションのCPU 要件をモニターする必要があります。この方法は、第2 章「Web サーバーのモニター」を参照してください。表表表 表 3-1 同時実行ユーザー同時実行ユーザー同時実行ユーザー同時実行ユーザーユーザー数ユーザー数ユーザー数ユーザー数1 1 _{ユーザー数 - ユーザーの合計。} 思考時間思考時間思考時間思考時間（秒）（秒）（秒）（秒）2 2 _思考時間_思考時間_思考時間思考時間 - ユーザーが実際にプロセッサを使用していない時間（リクエストとリクエストの間の時間）。サービスサービスサービスサービス時間時間時間時間（秒）（秒）（秒）（秒）3 3 _{サービス時間}_{サービス時間}_{サービス時間}_{サービス時間（秒）} - 1 ユーザーについて、操作を完了するまでの経過時間。同時ユーザーの同時ユーザーの同時ユーザーの同時ユーザーの範囲範囲範囲範囲4 4 _{同時ユーザーの範囲 - サーバー上で測定されたユーザー数。サーバー・ステータス表示（現在処理中} のリクエスト）のスナップショットから取得。サーバー・ステータスの詳細は、2-6 ページの「mod_ status ユーティリティを使用した Web サーバーのモニター」を参照してください。平均応答平均応答平均応答平均応答時間（秒）時間（秒）時間（秒）時間（秒）5 5 _{平均応答時間}_応答時間_応答時間応答時間 - 処理中のクライアントについて測定された応答時間応答時間応答時間応答時間。 1秒あたりの秒あたりの秒あたりの秒あたりのリクエスト数リクエスト数リクエスト数リクエスト数（スループット）（スループット）（スループット）（スループット）6 6 _{1 秒あたりのリクエスト数（スループット}_{スループット}_{スループット}_{スループット）}_{- 処理されたリクエスト数。} CPU 使用率（使用率（使用率（ 使用率（%））））7 7 _{CPU 使用率 - CPU 使用率合計の平均（パーセンテージ）。} 100 0 0.3 100 5.2 19 99 100 1 0.3 65-100 4.2 19 99 100 10 0.3 0-32 0.9 9 48 100 10 0.6 0-53 2.9 8 80 表表表 表 3-2 400 MHz x86 プロセッサプロセッサプロセッサプロセッサにおけるアプリケーションのにおけるアプリケーションのにおけるアプリケーションの CPU 要件におけるアプリケーションの要件要件要件アプリケーションアプリケーションアプリケーションアプリケーション CPU要件要件要件要件（リクエストあたり）（リクエストあたり）（リクエストあたり）（リクエストあたり）静的ページ、20KB 5msec

単純なサーブレット、JDK（Java Developer's Kit）リリース1.2

(36)

メモリー要件の決定

この項では、次のメモリー要件について説明します。 ■ Oracle HTTP Server のメモリー要件の決定 ■ JServ のメモリー要件の決定 ■ Java のヒープ・サイズの決定 ■ サーブレットおよびOracleJSP のメモリー要件の決定 ■ CPU あたりの JServ プロセス数の決定

Oracle HTTP Server

のメモリー要件の決定

親HTTP サーバー・プロセスは、常駐セットで最高 6MB 消費します。社内テストにおいて、リクエストを処理する子プロセスは、最高12MB 消費しました。

JServ

のメモリー要件の決定

JDK 1.2 を使用する JServ プロセスは、起動時に常駐セットで約 7MB 必要です。このプロセスによる使用量は増加し、12MB の物理メモリーを使用します。必要なメモリー・サイズはこれより大きくなる可能性がありますが、物理メモリーの使用セットで維持できるサイズは NT によって制限されるため、注意する必要があります。プロセスが非常に大きくなった場合、JServ プロセスにおけるページ・フォルトが多い可能性があり、そこから生じるページングにより、スループットが減少し、応答時間が長くなります。ただし、ホストに十分なメモリーが存在する場合、プロセスはページをシステム・ファイルのキャッシュに格納することが可能であるため、ページをディスクからフェッチする必要性が減少します。システム・ファイルのキャッシュ・メモリーは、必要な場合、システムによって再生されます。このため、Apache および JServ プロセスで最も注意する必要のあるカウンタは、ページ・フォルト数です（タスクマネージャの「プロセス」タブを参照）。一定してフォルト数が 1 秒あたり5 以上である場合、使用可能なシステム・メモリーはほとんどまたは全く存在しないため（タスクマネージャの「パフォーマンス」タブを参照）、物理メモリーを追加すると、パフォーマンスが改善される可能性があります。

Java

のヒープ・サイズの決定

JDK リリース 1.2 の場合、デフォルトの最大ヒープ・サイズは 67MB です。パフォーマンスを最大にするには、アプリケーション要件を満たす最大ヒープ・サイズを設定します。必要なJava ヒープを判断するには、ご使用のプログラムに java.lang パッケージの Runtime.getRuntime().totalMemory() および Runtime.getRuntime().freeMemoryメソッドのコールを挿入します。合計メモリーか

(37)

メモリー要件の決定 128MB のヒープが必要だと判断したとします。ヒープ・サイズを変更するには、自動モードの場合、jserv.properties ファイルの最大Java ヒープ・サイズを設定します。 wrapper.bin.parameters=-mx128m 手動モードの場合、複数のJServ プロセスが実行されているときは、ヒープ・サイズは各 JServ プロセスごとに、コマンドラインまたは起動スクリプトで設定する必要があります。 JServ プロセスが最大ヒープ・サイズを超えると、プロセスは終了します。自動モードの場合、新しいプロセスが開始されますが、パフォーマンスは著しく低下します。手動モードの場合、終了されたプロセスは再開されないため、ヒープ・サイズが十分な大きさであることを確認する必要があります。

サーブレットおよび

サーブレットおよび OracleJSP

OracleJSP

のメモリー要件の決定

一般的に、OracleJSP は、サーブレットよりも多くのメモリーを必要とします。 JDK リリース1.2 を使用した社内テストでは、サーブレットおよび OracleJSP の起動時の必要メモリー量は、7MB 弱でした。 OracleJSP では、JServ プロセス・サイズは 12MB まで増加し、その後多数のページ・フォルトが発生したため、スループットが低下し、平均応答時間が長くなりました。サーブレットの場合、単純なサーブレットのJServ プロセス・サイズは 8MB で安定しました。必要なメモリー量は、セッションが使用されているかどうかによっても異なります。セッションがオフの場合、OracleJSP およびサーブレットのいずれも約 8MB で安定しました。ページの一番上に次の行を含めることにより、セッションをオフに設定することが可能です。 <%@ page session="false" %> さらに、jserv.properties ファイルで、開発者モードを false に設定します。関連項目関連項目関連項目 関連項目 : 3-4 ページの「JServ のメモリー要件の決定」

(38)

メモリー要件の決定

CPU

あたりの

あたりの JServ

あたりの

JServ

プロセス数の決定

オラクル社では、基本的に、1 つの CPU あたり 2 つの JServ プロセスをお薦めします。社内テストで、サーバーで4 つの CPU と 1 つの JServ プロセスを使用した場合、負荷がかかると多くのリクエストが失敗しました。 2 つの JServ プロセスでは、若干のエラーは発生しましたが、負荷が増加した場合の応答時間は大幅に短縮されました。 4 つの JServ プロセスを使用した場合、パフォーマンスは許容範囲でした。 8 つの JServ プロセスを使用し、1 つの JServ プロセスあたりの同時リクエスト数を 10 に制限した場合、大きな負荷のもとでの応答時間は50% 短縮され、スループットが改善されました。 JServ プロセスあたりの同時リクエスト数を制限するには、jserv.properties ファイルの security.maxConnections パラメータを変更します。このパラメータにより、同時に処理されるJServ リクエストの最大数が指定されます。デフォルト設定の 50 を使用した場合、全体的な受信負荷が制限されていない限り（httpd.conf ファイルの ThreadsPerChild値の減少により）、負荷のもとでの応答時間が指数的に増加しました。オラクル社では、JServ プロセスにおける同期化のボトルネックを防ぐために、 security.maxConnectionsを10 に制限することをお薦めします。ご使用のHTTP サーバーのリクエストのうち多数が JServ 以外のものである場合を除き、次の式のとおりであることを確認します。そうでない場合、負荷が大きいと、HTTP サーバーと JServ エンジン間の接続エラーによりリクエストはエラーになります。 HTTP サーバーは、リスト内の次の JServ プロセスにリクエストを渡しますが、security.maxConnections 値を超えているため、接続を待機する必要があり、応答時間が著しく長くなります。ご使用のアプリケーション・コードで同期化を頻繁に行ったり、新しいJava オブジェクトを多数作成する場合、JServ プロセスの数を増やし、一方で 1 プロセスあたりのスレッド数を10 から 20 に制限することを考慮する必要があります。これにより、JVM（Java 仮想マシン）のオブジェクトの同期化に必要なキューイングや処理の増加を回避できます。 httpd プロセスが着信リクエストを分散してJServ プロセスに送信するためです。注意注意注意 注意 : ご使用のサーブレットでSingleThreadModel インタフェースがインプリメントされている場合、security.maxConnections の値を singleThreadModelServlet.maximumCapacity値（デフォルトは 10）より小さくする必要があります。

（JServ プロセス数）x（security.maxConnections） =（ThreadsPerChild 値）x 2

Oracle9i Application Server for Windows NT Oracle HTTP Server powered by Apacheパフォーマンス・ガイド, リリース1.0.2