10gリリース3（10.1.3.1.0）
B31836-02
 目次 |
 索引 |
| Oracle Application Server パフォーマンス・ガイド 10gリリース3（10.1.3.1.0） B31836-02 |
|
この章では、Oracle Application Serverのパフォーマンスとチューニングの概要を説明します。
この章には、次の項が含まれています。
Oracle Application Serverのパフォーマンスを最大限に発揮するには、すべてのコンポーネントの監視、分析およびチューニングが必要です。このドキュメントの各章では、パフォーマンス監視に使用するツールと、Oracle HTTP Server、Oracle Containers for J2EE（OC4J）などのOracle Application Serverコンポーネントのパフォーマンスを最適化するテクニックについて説明します。
次に、このマニュアルで使用されているパフォーマンスに関する用語を示します。
複数のリクエストを同時に処理する能力。同時実行性メカニズムの例には、スレッドおよびプロセスがあります。
リソースの競合。
アルゴリズムを使用してテキスト文字列から生成された数値。通常、ハッシュ値はテキストに比べてかなり小さくなります。ハッシュ数値は、セキュリティ、およびデータへの高速なアクセスの目的で使用されます。
全体のタスクを完了するために、あるシステム・コンポーネントが別のコンポーネントを待機している時間。待ち時間は、無駄な時間として定義できます。ネットワークのコンテキストでは、待ち時間はパケットのソースから宛先への移動時間として定義されます。
リクエストの送信からレスポンスの受信までの時間。
ハードウェア・リソースに十分な余裕さえあれば、これに応じたスループットを発揮するシステムの能力。スケーラブルなシステムとは、レスポンス時間およびスループットに悪影響を与えずに、増加したリクエストの処理が可能なシステムです。
リクエストの受信から、そのリクエストに対するレスポンスの完了までの時間。
ユーザーが実際にプロセッサを使用していない時間。
単位時間当たりに処理されるリクエスト数。
リクエストの送信からリクエストの開始までの時間。
パフォーマンスは、事前に設定しておく必要があります。アプリケーションの分析および設計中にパフォーマンス要件を予測し、最適なパフォーマンスのコストと利益を考慮する必要があります。この項では、次のような基本概念について説明します。
レスポンス時間は、サービス時間と待機時間の合計であるため、次の方法でパフォーマンスを向上できます。
図1-1に、1つのリソースに対して10個の順次タスクが時間の経過に沿って競合している状態を示します。
図1-1で示す例では、タスク1のみが待機時間なしで実行されます。タスク2はタスク1が完了するまで待機し、タスク3はタスク1と2が完了するまで待機する必要があります。他のタスクについても同様です。この図では各タスクの大きさは同じですが、実際のタスクのサイズはそれぞれ異なります。
複数のリソースを使用したパラレル処理の場合、より多くのリソースをタスクに割り当てることができます。各タスクは専用のリソースを使用してすぐに実行され、待機時間が発生しません。
Oracle HTTP Serverでは、このように、クライアントのリクエストを使用可能なhttpdプロセス（またはスレッド）に割り当てて処理します。MaxClientsディレクティブにより、クライアントのリクエストを同時に処理可能なhttpdプロセス数の上限を指定します。使用中のプロセス数がMaxClients値に達すると、リクエストが完了して、プロセスが解放されるまで、サーバーでは接続が拒否されます。
システム・スループットは、一定時間内に完了する処理量です。スループットは、次の方法で増加できます。
1つのタスクのサービス時間が同じ場合でも、競合が増加すると待機時間は長くなります。1秒を要するサービスを多数のユーザーが待っている場合、10番目のユーザーは9秒間待機する必要があります。図1-2に、待機時間とリソースに対する競合の関係を示します。この図のグラフは、リソースの競合が増加するにつれて、待機時間が指数関数的に増加することを示しています。
CPU、メモリー、I/O容量およびネットワーク帯域幅などのリソースは、サービス時間短縮の重要な要素となります。リソースを増加すると、スループットが増加し、レスポンス時間も短縮できます。パフォーマンスは次の要因に依存します。
図1-3に、サービスの完了までにかかる時間と需用率との関係を示します。この図のグラフは、リクエストの単位数が増加するにつれて、サービスにかかる時間が増加していることを示しています。
この状況を解消するには、2つの方法があります。
過度の需要により、レスポンス時間が増加し、スループットが減少します。この様子を図1-4のグラフに示します。
需用率がスループットの限界を超えた場合、監視によって、どのリソースが使い果たされてしまったかを判断し、可能であれば、そのリソースを増加します。
パフォーマンスに関する問題は、次のような調整により解決できます。
リクエスト当たりのリソース（CPU、メモリー）の消費の削減により、パフォーマンスを改善できます。これは、プーリングおよびキャッシングにより実現できます。
問題によっては、処理のスケジュールを変更したり、処理を分散しなおすことによって解決できます。
リソース（CPUなど）の増加や再割当てによって問題を解決できる場合があります。
システムを設計する場合もメンテナンスを行う場合も、最適化の手段および対象を判断できるよう、具体的なパフォーマンス目標を設定する必要があります。特定の目標を持たずにパラメータを変更すると、目立った効果もなくシステムのチューニングに余分な時間を費やすことになります。
具体的なパフォーマンス目標の例として、注文入力のレスポンス時間を3秒以内にする、などがあります。アプリケーションがその目標を達成できない場合、原因（たとえばI/O競合など）を識別して対処します。開発中にアプリケーションをテストして、設計時に設定されたパフォーマンス目標を達成できるかどうかを調べます。
通常、チューニングには他の面とのトレード・オフが発生します。ボトルネックを判断できたら、目標を達成するために、他の部分のパフォーマンスを変更する必要がある場合もあります。たとえば、I/Oが問題である場合、メモリーまたはディスクの購入が必要な場合があります。購入できない場合は、目標のパフォーマンスを得るためにシステムの同時実行性を制限する必要があります。ただし、パフォーマンスの目標が明確に定まっていれば、何が最も重要かがわかっているため、パフォーマンス向上のために何を犠牲にするかの判断が容易になります。
アプリケーション開発者、データベース管理者およびシステム管理者は、ユーザーが期待しているパフォーマンスを、注意しながら適切に設定する必要があります。システムが特に複雑な処理を行っている場合は、単純な処理を行っている場合よりもレスポンス時間が長くなる可能性があります。どの処理に時間がかかるかを明確にユーザーに知らせる必要があります。
パフォーマンス目標を明確に定めると、パフォーマンスのチューニングが成功したかどうか、容易に判断できます。チューニングの成功を左右するのは、ユーザー・コミュニティに対して設定した機能面での目標、基準が満たされたかどうかを判断する能力、そして例外事項を解決するための対策を講じる能力です。
常にパフォーマンスを監視することにより、十分にチューニングされたシステムを維持できます。アプリケーションのパフォーマンスの履歴を記録することにより、有効な比較が可能となります。様々な大きさの負荷に関する実際のリソース消費データを使用して、客観的なスケーラビリティの調査を行うことにより、予期される負荷のボリュームに合せたリソース要件を予測できます。
システムの最適効率を実現するためには、計画、監視および定期的な調整が必要です。パフォーマンス・チューニングの最初のステップは、目標を決定し、使用可能なテクノロジを効率的にアプリケーションに使用するよう設計することです。システムの実装後は、システムの監視と調整を定期的に行う必要があります。たとえば、ユーザーの90%についてレスポンス時間が5秒以下であり、全ユーザーについても最大で20秒以下のレスポンス時間であるといったことを確認するとします。通常、これは簡単なことではありません。アプリケーションには、それぞれ特徴および許容できるレスポンス時間が異なる様々な処理が含まれます。それぞれのアプリケーションに対し、適切な目標を設定する必要があります。
また、負荷の変動も判別する必要があります。たとえば、図1-5のグラフに示すように、ユーザーはシステムに午前9時から10時に集中的にアクセスし、再び午後1時から2時に集中的にアクセスする場合があります。毎日あるいは毎週など、定期的に負荷のピークが発生する場合、一般的には負荷のピーク時の要件に合せてシステムを構成し、チューニングします。ピーク時以外にアプリケーションにアクセスするユーザーに対するレスポンス時間は、ピーク時のユーザーの場合よりも短くなります。負荷のピークが頻繁に発生しない場合は、少ないハードウェア構成でコストを抑えるために、負荷のピーク時にはレスポンス時間が長くても我慢することも考えられます。
パフォーマンスは、様々な領域にまたがっています。
|
 Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|