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

(1)

Oracle9i Application Server for Windows NT/2000

Oracle HTTP Server powered by Apache パフォーマンス・ガイド

リリース 1.0.2.2

2001 年 10 月部品番号 : J04270-01

(2)

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

部品番号 : J04270-01

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

原本部品番号：A86676-02

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

Restricted Rights Notice

Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, 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-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

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

(3)

はじめに

... v 対象読者 ... vi このマニュアルの編成 ... vi 関連ドキュメント ... vii マニュアルの表記規則 ... vii

1 パフォーマンスの概要

パフォーマンスの概要

パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語パフォーマンスに関する用語 ... 1-2 パフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとはパフォーマンスのチューニングとは ... 1-2 応答時間 ... 1-3 システム・スループット ... 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

(4)

パフォーマンスモニタの起動 ... 2-3 プロセス・アクティビティのグラフの作成 ... 2-3 パフォーマンス統計のロギング ... 2-4 ログ・ファイル・データのレポートまたはグラフの作成 ... 2-5 Web サーバーのモニターサーバーのモニターサーバーのモニターサーバーのモニター ... 2-6 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-3 サーブレット・リクエストの ThreadsPerChild の設定 ... 4-3 静的ページのリクエストの ThreadsPerChild の設定 ... 4-3 SSL セッション・キャッシュを使用可能にするセッション・キャッシュを使用可能にするセッション・キャッシュを使用可能にする ... 4-4セッション・キャッシュを使用可能にするロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響についてロギングのパフォーマンスへの影響について ... 4-4 HTTP/1.1 プロトコルの利点プロトコルの利点プロトコルの利点プロトコルの利点 ... 4-5 永続的な接続のサポート ... 4-5

5 Apache JServ の最適化

の最適化

JServ の概要の概要の概要の概要 ... 5-2 サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化サーブレットのパフォーマンスの最適化 ... 5-3 サーブレット・クラスのロード ... 5-3 サーブレット・クラスの自動リロード ... 5-3

(5)

OracleJSP とはとはとはとは ... 5-7 OracleJSP のパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニングのパフォーマンス・チューニング ... 5-8 セッション管理の影響 ... 5-8 開発者モード ... 5-8 バッファリング ... 5-8 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)

マニュアルの表記規則

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

テキストの表記規則

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

(10)

コード例の表記規則

コード例では、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 ユーザーで接続します。表記規則表記規則表記規則表記規則意味意味意味意味例例例例 [ ] 大カッコ内には、1 つ以上のオプションの項目が含まれます。大カッコは入力しないでください。

DECIMAL (digits [ , precision ])

{ } 中カッコ内には 2 つ以上の項目が含まれ、そのうちの 1 つが必須であることを示します。中カッコは入力しないでください。 {ENABLE | DISABLE} | 縦線は、大カッコまたは中カッコ内の選択肢を示します。これらのオプションのうちの 1 つを入力します。縦線は入力しないで {ENABLE | DISABLE} [COMPRESS | NOCOMPRESS]

(11)

... 横方向の省略記号は、次のいずれかを示します。

■ コード中で例に直接関係のない部分が

省略されている。

■ コードの一部が繰返し可能である。

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;

sqlplus hr/hr 表記規則

表記規則表記規則

(12)

(13)

1

パフォーマンスの概要

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

(14)

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

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

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

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

(15)

パフォーマンスのチューニングとは ■ 過度の需要による影響 ■ 問題解決のための調整

応答時間

応答時間応答時間応答時間応答時間はサービス時間サービス時間サービス時間サービス時間と待機時間待機時間待機時間の合計であるため、次の方法でパフォーマンスを向上で待機時間きます。 ■ 待機時間待機時間を削減する待機時間待機時間 ■ サービス時間サービス時間を削減するサービス時間サービス時間図 1-1に、1 つのリソースに対して 10 個のタスクが競合している状態を示します。図図図 図 1-1 個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理個別のタスクの順次処理この例では、待機時間なしで実行されるのはタスク 1 のみです。タスク 2 はタスク 1 が完了するまで待機し、タスク 3 はタスク 1 と 2 が完了するまで待機する必要があります。他のタスクについても同様です。（この図では各タスクの大きさは同じですが、実際のタスクのサイズはそれぞれ異なります。）関連項目関連項目関連項目 関連項目 : パフォーマンス要件、およびシステムのどの部分をチューニ ングするかを判別する方法については、1-7 ページの「パフォーマンス目標の設定」を参照してください。 1 2 3 4 5 6 7 8 9 10

(16)

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

システム・スループット

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

待機時間

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

(17)

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

重要なリソース

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

(18)

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

過度の需要による影響

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

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

問題解決のための調整

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

(19)

パフォーマンスの評価

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

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

ユーザーの期待値の設定

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

パフォーマンスの評価

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

(20)

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

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

(21)

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

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

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

(22)

アーキテクチャ

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

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

■ Apache JServ ■ OracleJSP

図図図

(23)

2

Web サーバーのモニター

サーバーのモニター

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

(24)

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

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

(25)

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

パフォーマンス

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

モニタの起動

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

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

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

(26)

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

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

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

(27)

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

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

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

(28)

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

Web サーバーのモニター

サーバーのモニター

パフォーマンスのチューニングには、システム・アクティビティのモニターが不可欠です。 Oracle HTTP Server では、mod_status モジュールを使用して、現在のサーバー統計を含め、サーバー側のステータス情報が提供されます。これらのサーバー・ステータス・レポートを取得するには、次の各項で説明するように Web サーバーを設定する必要があります。

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

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

ユーティリティを使用した 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 は、モニターするホスト名およびポートです。これらの 統計により、ご使用のシステムの混雑状況を知ることができます。次の内容が表示されます。 ■ 表示中のステータスのホスト名 ■ サーバーのバージョン ■ サーバーが構築された日付

(29)

Web サーバーのモニター ■ アイドル状態のサーバー数 ■ 現在のサーバーの状態（たとえば、接続待機中、リクエストの読込み中、応答の送信中など）図 2-2に、ExtendedStatus が On になっているサーバー・ステータス・ページのスナップショットを示します。

(30)

Web サーバーのモニター

図図図

(31)

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 サーバー統計表示サーバー統計表示サーバー統計表示サーバー統計表示

(32)

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. モニターするホストをクリックします。

(33)

JServ プロセスのモニター

図図図

(34)

(35)

3

サイズ設定および構成

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

(36)

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

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

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

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

(37)

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 5ms

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

(38)

メモリー要件の決定

この項では、次のメモリー要件について説明します。 ■ 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 メソッドのコールを挿入します。合計メモリーか

(39)

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

サーブレットおよび

サーブレットおよび OracleJSP のメモリー要件の決定

のメモリー要件の決定

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

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