| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース2 (11.1.2) B71702-01 |
|
 前 |
 次 |
この章では、Oracle HTTP Serverのパフォーマンスを最適化する手法について説明します。この章の内容は次のとおりです。
|
注意: この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。 |
Oracle HTTP Server(OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Serverのリスナーと静的ページ、動的ページおよびWeb上のアプリケーションのホスティングのフレームワークを提供します。Oracle HTTP ServerはApache 2.2.xインフラストラクチャをベースとし、オラクル社が開発したモジュールを含んでいます。シングル・サインオン、クラスタ化されたデプロイおよび高可用性の機能がOracle HTTP Serverの動作を強化しています。
詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。
オープンソースのApacheソフトウェア・インフラストラクチャの詳細は、Apache Software FoundationのWebサイト(http://www.apache.org/)を参照してください。
Oracle Fusion Middlewareでは、Oracle HTTP Serverの実行時のパフォーマンスが絶えず自動的に測定されます。パフォーマンス・メトリックは自動的に有効になります。パフォーマンス・メトリックを収集するためにオプションを設定したり、追加構成を行ったりする必要はありません。アプリケーションの実行に時間がかかる、アプリケーションがハングしている、などの問題が発生した場合は、特定のメトリックを参照して、問題の詳細を確認できます。
|
注意: Fusion Middleware Controlにはリアルタイム・データが表示されます。Fusion Middleware Controlを使用してHTTP Serverのパフォーマンス・メトリックを確認する方法の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverのパフォーマンスの監視に関する項を参照してください。 履歴データを参照する必要がある場合は、Grid Controlの使用を検討してください。第4.8項「Oracle Enterprise Manager 11g Grid Control」を参照してください。 |
Fusion Middleware Controlに加えて、Oracle HTTP Serverはあらゆる機能部分のメトリックを収集するDynamic Monitoring Service(DMS)も備えています。これらのメトリックを必要に応じて確認することで、特定の時点におけるシステムの動作を把握できます。Oracle HTTP Serverのすべてのレイヤーについて、メモリー、CPU情報、ならびにリクエスト処理の最小時間、最大時間および平均時間が表示されます。さらに、実際の使用状況に基づいてシステムをチューニングする際に役立つ負荷レベル、スレッド数、アクティブ接続数などの詳細も表示されます。
メトリックを監視するには、Oracle Enterprise Managerまたはスパイ・サーブレットを使用します。第4章「Oracle Fusion Middlewareの監視」を参照してください。OHSのDMSメトリックを確認するもう1つの方法を次の例に示します。
cd $INSTANCE_HOME/bin
./opmnctl metric op=query COMPONENT_NAME=<component_name> dmsarg=[name=/OHS/Modules/<module_name>.c
例:
./opmnctl metric op=query COMPONENT_NAME=ohs1 dmsarg=[name=/OHS/Modules/mod_cgi.c
./opmnctl metric op=query COMPONENT_NAME=ohs1 dmsarg=[name=*]
次のチューニング構成により、Oracle HTTP Serverのパフォーマンスを改善できる場合があります。必ず各自のユースケースを検討して、これらの設定をデプロイメントに適用できるかどうかを判断してください。
Oracle HTTP Serverでは、httpd.confのディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。
Oracle HTTP Serverの構成の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの管理ツールに関する項を参照してください。
Oracle HTTP Serverは、デフォルトで、3種類のMulti-Processing Module(MPM)をサポートしています。サポートされているMPMは次のとおりです。
Worker: これは、マルチプロセス-マルチスレッド・モデルを採用しており、Microsoft Windowsプラットフォームを除くすべてのプラットフォームのデフォルトMPMです。マルチスレッド・サポートによってシステム・リソースの使用量が減少するため、スケーラビリティが向上し、マルチプロセス・サポートによって安定性が向上します。
WinNT: このMPMはWindowsプラットフォーム専用です。親プロセスと子プロセスで構成されています。親プロセスは制御プロセスであり、子プロセスはリクエストを処理するスレッドを作成します。
Prefork: これは、Apache 1.3.x方式に準拠しており、スレッドのかわりにプロセスを使用します。最も効率性の低いMPMとみなされています。
各MPMタイプのディレクティブは、ORACLE_INSTANCE/config/OHSComponent/<ohsname>/httpd.confファイルにあります。デフォルトのMPMタイプはWorker MPMです。別のMPM(Prefork MPMなど)を使用する場合は、ORACLE_HOME/ohs/bin/apachectlファイルを編集してください。
|
注意: この章の内容は、Worker MPMおよびWinNT MPM(どちらもスレッドを使用)の使用を前提としています。次に示すディレクティブは、Prefork MPMを使用する場合は適用されない可能性があります。Apache 1.3.xまたはApache 2.2ベースのOracle HTTP ServerをPrefork MPMとともに使用する場合は、Oracle Application Server 10g リリース3のドキュメント( |
表6-1 Oracle HTTP Serverの構成プロパティ
| ディレクティブ | 説明 |
|---|---|
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「キューの長さ: 最大」フィールドにマップされます。 |
保留中の接続のキューの最大長を指定します。通常、チューニングは不要です。一部のオペレーティング・システムでは、バックログとして指定した数値そのものが使用されるのではなく、設定値に基づいた数値(通常は設定値より大きい数値)が使用されることに注意してください。 デフォルト値: 511 |
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大リクエスト数」フィールドにマップされます。 このパラメータは、mod_winnt(Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しており、 |
稼働しているサーバーの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、
これとは逆に、システム・リソースが飽和状態のときに サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpd/スレッド・サーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとして 十分なキャパシティがある場合は、
デフォルト値: 150 |
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「初期子サーバー・プロセス」フィールドにマップされます。 |
起動時に作成される子サーバー・プロセスの数を指定します。再起動後に急激な負荷が予想される場合は、必要な子サーバーの数に基づいてこの値を設定してください。 次のパラメータは相関関係にあり、UNIXプラットフォーム(worker_mpm)にのみ適用されることに注意してください。
Windowsプラットフォーム(mpm_winnt)では、UNIXプラットフォームの場合と同様に、次のパラメータをチューニングすることが重要です。
各子プロセスには、実際にリクエストを処理する子スレッドが定義されていることに注意してください。このディレクティブと関連して
デフォルト値: 2 |
|
このパラメータは、mod_winnt(Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しています。 |
作成可能なサーバー(子)・プロセスの数の上限を指定します。 デフォルト値: 16 |
|
|
サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。 デフォルト値:
|
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1子サーバー・プロセス当たりのスレッド数」フィールドにマップされます。 |
起動時に各サーバー(子)・プロセスで作成されるスレッドの数を設定します。 デフォルト値: mpm_winntを使用する場合は64、Worker MPMを使用する場合は25です。
起動時に、Oracle HTTP Serverが親プロセスを作成します。親プロセスは、 起動後は、負荷の状態に応じて、システムのサーバー・プロセス数とサーバー・スレッド(サーバー・プロセスの子)数が 次のディレクティブは、前述のディレクティブに対する制限を制御します。次のディレクティブを有効にするには、前述のディレクティブより先に定義する必要がありますので注意してください。
|
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1子サーバー・プロセス当たりの最大リクエスト数」フィールドにマップされます。 |
各子プロセスが終了するまでに処理可能なリクエストの数を指定します。子プロセスは、長期間使用するうちにApache(およびApacheが使用するその他のライブラリ)でメモリーまたはその他のリソースのリークが発生して問題が生じることのないよう、自動的に終了します。ほとんどのシステムでは、これは不要ですが、UNIXシステムの中には、ライブラリで著しいリークが発生するものがあります。このようなプラットフォームについては、 この値には、各接続の初期リクエストに続く デフォルト値: 0 注意: Windowsシステムでは、サーバー・プロセスが1つしかないため、 |
|
これらのディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大アイドル・スレッド」フィールドおよび「最小アイドル・スレッド」フィールドにマップされます。 これらのパラメータは、mod_winnt(Windowsプラットフォーム)では使用できませんので注意してください。 |
サーバープールのサイズを制御します。Oracle HTTP Serverは、必要なサーバー・スレッドの数を予測するかわりに、実際の負荷に動的に適応します。サーバーは、現在の負荷を処理するのに十分なサーバー・スレッドに加え、一時的な負荷の増大(単一のブラウザから複数のリクエストを同時に受信した場合など)に備えて、予備のサーバー・スレッドもいくつか保持しておこうとします。 そのために、サーバーはリクエストを待っているサーバー・スレッドの数を定期的にチェックします。それが デフォルト値: MaxSpareThreads: 75 MinSpareThreads: 25 |
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「リクエスト・タイムアウト」フィールドにマップされます。 |
受信および送信がタイムアウトするまでの時間(秒)。 デフォルト値: 300 |
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドにマップされます。 |
永続的な接続(1接続当たり複数のリクエスト)を許可するかどうか。Offに設定すると、無効になります。 デフォルト値: On |
|
永続的な接続の間に許可するリクエストの最大数。0に設定すると、無制限に許可されます。 長時間にわたるクライアント・セッションがある場合は、この値を大きくすることを検討してください。 デフォルト値: 100 |
|
|
このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドの下にある「接続タイムアウト(秒)を許可」フィールドにマップされます。 |
1つの接続において同じクライアントからの次のリクエストを待つ時間(秒)。 デフォルト値: 5秒 |
|
|
オープン・ファイルまたはオープン・ネットワーク・ソケットに対して読取りまたは書込みを行うためにプログラムで使用するオブジェクトの数。使用可能なファイル・ディスクリプタの不足は、オペレーティング・システムのパフォーマンスに影響を与える可能性があります。 ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するシェル・スクリプトで強い制限( ファイル・ディスクリプタ制限の構成は、プラットフォーム固有であることに注意してください。詳細は、オペレーティング・システムのドキュメントを参照してください。 |
ブラウザが永続的な接続をサポートしている場合、Oracle HTTP ServerのKeepAliveディレクティブを使用すれば、サーバーでも永続的な接続をサポートできます。永続的な接続を使用すると、サーバーのワークロードが減少するため、パフォーマンスが向上します。永続的な接続を有効にした場合、サーバーでは、クライアントへの接続を設定する作業を繰り返す必要がなくなります。
KeepAliveディレクティブのデフォルト設定は次のとおりです。
KeepAlive on MaxKeepAliveRequests 100 KeepAliveTimeOut 5
これらの設定では、永続的な接続のメリットを享受しながら、デメリットを最小限に抑えることができるように、1接続当たりのリクエスト数とリクエストの間隔が設定されています。これらの値を設定する際には、ご使用のシステムのユーザー数とユーザーの取る行動を考慮する必要があります。たとえば、ユーザー数は多いが、ユーザーからのリクエストが小さく、頻度も低い場合は、KeepAliveディレクティブのデフォルト設定を小さくするか、KeepAliveをoffに設定します。ユーザー数が少なく、サイトのアクセス頻度が高い場合は、設定を大きくします。
KeepAliveオプションは、MaxClientsディレクティブとともに慎重に使用してください。KeepAliveオプションは、タイムアウトするか、リクエスト数がMaxKeepAliveRequestsで指定した制限に達するまで、確立済の接続にワーカー・スレッドを結び付けます。つまり、ListenBacklogキュー内の接続またはユーザーは、キープ・アライブ・ユーザーがワーカーを解放するまで、ワーカーが不足した状態になります。リソースの不足は、ユーザー数がMaxClientsに指定した数より常に多いようなKeepAliveユーザー負荷に対して発生します。
|
注意:
|
MaxClientsを大きくした場合、パフォーマンスに次のような影響が出ます。
MaxClientsの数値が大きいと、システム・リソースに過負荷がかかり、パフォーマンスの低下につながる可能性があります。
ユーザー数が多く、リクエストが少ない場合は、リソース不足が起きないように、MaxClientsを大きくしてKeepAlive接続をサポートすることを検討してください。この場合、ユーザーの同時実行性が向上すると、全体的なパフォーマンスに影響が出る可能性がありますので注意してください。システム・パフォーマンスが同時実行性向上の影響を受け、システム障害を引き起こすことがあります。
MaxClientsは常に、システムが安定し、最適なパフォーマンスが得られる(CPU使用率が最大85%)ような値に設定してください。
一般に、ユーザー数が多く、リクエストの頻度が低い場合は、リソース不足が起きないように、KeepAliveオプションをoffにするか、ごく小さい値まで減らすことを検討してください。
KeepAlive接続を無効にした場合、パフォーマンスに次のような影響が出ます。
リクエストごとに接続を確立するため、コストがかかります。
接続を作成してクローズする頻度が高くなると、システム・リソースがある程度使用されます。TCP接続では、ソケット接続およびオープン・ファイル・ディスクリプタをクローズするまでのtime_wait間隔が接続ごとに設定されています。time_waitのデフォルト値は60秒です。つまり、サーバーが接続を解放した後も、各接続をクローズするまでに60秒かかる可能性があります。
|
警告: パフォーマンスの問題が発生するのを避けるために、パラメータの値は、必ずワークロードの性質およびシステムのキャパシティを考慮したうえで設定してください。 |
この項では、ロギングのタイプ、ログ・レベル、およびロギングを使用した場合のパフォーマンスへの影響について説明します。
一般に、アクセス・ログは誰が何にアクセスしたかを追跡する目的で有効にします。ORACLE_INSTANCE/diagnostics/logs/OHS/ohsnameディレクトリにあるaccess_logファイルには、処理されたリクエストごとにエントリが1つ含まれています。このファイルは次第に大きくなるため、ディスク領域を消費する可能性があります。ワークロードの性質によっては、access_logはパフォーマンスにほとんど影響を与えません。パフォーマンスが問題になっていることに気づいた場合、他のプロキシまたはロード・バランサが使用されていて、同じ情報が得られるのであれば、access_logファイルを無効にしてもかまいません。
デフォルトでは、HostNameLookupsディレクティブはOffに設定されています。サーバーは、受信リクエストのIPアドレスをログ・ファイルに書き込みます。HostNameLookupsがOnに設定されている場合、サーバーはインターネット上のDNSシステムに問い合せて、各リクエストのIPアドレスに関連付けられているホスト名を特定し、そのホスト名をログに書き込みます。サーバーの負荷およびDNSサーバーへのネットワーク接続によっては、DNS HostNameLookupがパフォーマンスに与える影響が大きくなります。可能であれば、IPアドレスのみをログに記録することを検討してください。UNIXシステムでは、ORACLE_HOME/Apache/Apache/bin/ディレクトリにあるlogresolveユーティリティを使用して、オフラインの状態でIPアドレスをホスト名に解決できます。
サーバーは、異常なアクティビティをエラー・ログに記録します。ORACLE_INSTANCE/diagnostics/logs/OHS/ohsnameディレクトリにあるohsname.logファイルには、エラー、警告、システム情報および通知(ログレベル設定による)が含まれています。
httpd.confファイルには、OHSのエラー・ログ構成が含まれています。ロギング・モードはOraLogModeディレクティブで定義されます。デフォルトはodl-textです。この場合、Oracle診断ロギング・フォーマットがテキスト・ファイルに生成されます。これをodl-xmlに変更すると、Oracle診断ロギング・フォーマットがXMLファイルに生成されます。
Oracle診断形式のロギングの場合、OraLogSeverityディレクティブを使用してログ・レベルを設定します。
Apache形式のロギングの場合、ErrorLogディレクティブとLogLevelディレクティブを使用して、ログ・ファイル、および記録されるメッセージの詳細度を指定します。デフォルトのデバッグ・レベルはWarnです。
過度のロギングを行うと、パフォーマンス・コストが発生し、ディスク領域も占有してしまう可能性があります。ログ・レベルの制御は、必要に応じて使用してください。動的リソースを使用するリクエスト(たとえば、mod_ossoまたはmod_plsqlを使用するリクエスト)の場合、debugレベルなど高いデバッグ・レベルを設定すると、それに伴ってパフォーマンス・コストが発生します。
この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってご使用のHTTP Serverのパフォーマンスが改善されるかどうかを判断してください。
この項の内容は次のとおりです。
Secure Sockets Layer(SSL)は、Netscape社によって開発されたプロトコルで、インターネット上での認証および暗号化通信を可能にします。概念的には、SSLはプロトコル・スタックのアプリケーション層とトランスポート層の中間に存在します。SSLは、技術的にはアプリケーションに依存しないプロトコルですが、HTTP経由のセキュリティを提供するための標準となり、すべての主要なWebブラウザでサポートされています。
SSLは、Webベースのアプリケーションのレスポンス能力とスケーラビリティの両方でボトルネックとなる可能性があります。SSLが必要な場合は、プロトコルのパフォーマンスに関する問題を慎重に考慮してください。一般に、SSLプロトコルを使用するうえで最もパフォーマンス・コストがかかるのは、特にセッションの作成や初期化などのセッション管理です。
この項には、SSLのパフォーマンスに関連した次の情報が含まれています。
|
関連項目: Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド |
SSL接続が初期化されると、クライアントとサーバーの間でセッションベースのハンドシェイクが発生します。これには、暗号スイートのネゴシエーション、データ暗号化用の秘密鍵の交換、ならびにデジタル署名証明書を介したサーバーおよびクライアント(オプション)の認証が含まれます。
SSLのセッション状態がクライアントとサーバーの間で開始されれば、そのセッション状態を保存して再利用できるので、その後のSSLリクエストでセッション作成のためのハンドシェイクを行う必要はなくなります。Oracle HTTP Serverは、デフォルトでクライアントのSSLセッション情報をキャッシュします。セッション・キャッシュを使用すると、待機時間が長いのはサーバーへの最初の接続時のみになります。
ssl.confのSSLSessionCacheTimeoutディレクティブにより、保存されたSSLセッションをサーバーが保持する期間を指定します(デフォルトは300秒です)。セッション状態は、指定の時間が経過しても使用されない場合は破棄されます。その後のSSLリクエストでは、新しいSSLセッションを確立し、もう一度ハンドシェイクを開始する必要があります。SSLSessionCacheディレクティブでは、SSLセッション情報の保存場所を指定します(デフォルトの場所は次のディレクトリです)。
$ORACLE_INSTANCE/diagnostics/logs/$COMPONENT_ TYPE/$COMPONENT_NAME
保存されたセッション・キャッシュ・ファイルは、複数のOracle HTTP Serverプロセスで使用できることに注意してください。
SSLのセッション状態を保存すると、SSLを使用したアプリケーションのパフォーマンスが大幅に向上します。たとえば、SSL対応のサーバーで接続と切断の簡単なテストを行ったところ、SSLセッション・キャッシュを使用しない場合、5回の接続に要した時間は11.4秒でした。SSLセッション・キャッシュを使用可能にした場合、5回のラウンドトリップに要した時間は1.9秒でした。
保存されたSSLのセッション状態を再利用する場合は、いくつかのパフォーマンス・コストが発生します。SSLのセッション状態をディスクに保存した場合、保存されたセッション状態を再利用するには、通常ディスクから関連するセッション状態を検出し、取得する必要があります。永続的なHTTP接続を使用すれば、このパフォーマンス・コストを削減できます。永続的なHTTP接続がクライアント側でサポートされている場合、Oracle HTTP Serverはこの接続をデフォルトで使用します。Oracle HTTP Serverによって実装されるSSLを使用したHTTP接続では、SSLのセッション状態は、関連するHTTP接続が維持されている間メモリーに保存されます。このプロセスにより、SSLセッションの再利用に伴うパフォーマンスへの影響が実質的に排除されます(概念的には、SSL接続はHTTP接続とともに維持されます)。詳細は、第6.3.2項「永続的な接続によるhttpdプロセスの可用性の低下」を参照してください。
SSLを使用するほとんどのアプリケーションでは、データ暗号化のコストは、SSLセッション管理のコストと比べればわずかです。著しい暗号化コストが発生するのは、暗号化されたデータのボリュームが大きい場合です。そのような場合、SSLセッションに対して選択したデータ暗号化アルゴリズムおよび鍵のサイズはきわめて大きくなります。通常、セキュリティ・レベルとパフォーマンスの間にはトレードオフが発生します。
Oracle HTTP Serverは、ssl.confで指定されているSSLCipherSuite属性に基づき、クライアントと暗号スイートをネゴシエートします。OHS 11gでは、デフォルトで128ビットの暗号化アルゴリズムが使用されており、それより低いレベルの暗号化はサポートを終了しました。Windowsの場合、旧リリース[10.1.3x]では64ビットの暗号化が使用されていました。UNIXの場合、10.xリリースでは128ビットの暗号化が使用されていました。
|
関連項目: サポートされている暗号スイートの使用の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。 |
次の推奨事項は、Oracle HTTP ServerをSSLとともに使用する場合のパフォーマンス要件を決定する際に役立ちます。
SSLハンドシェイクは、CPU使用率とレスポンス時間のどちらから見ても、本質的にリソース消費量の多いプロセスです。したがって、SSLは必要な場合にのみ使用しください。アプリケーションの中でセキュリティを必要とする部分と要求されるセキュリティ・レベルを見極め、この部分のみを必要なセキュリティ・レベルで保護します。SSLの使用を控え、可能なかぎりセッション状態を再利用して、SSLハンドシェイクの必要性を最小限に抑えます。たとえば、ページ上に少量の機密データと多量の機密ではないグラフィック画像がある場合、機密データの転送にのみSSLを使用し、画像の転送には通常のHTTPを使用します。アプリケーションでサーバー認証のみが必要とされている場合、クライアント認証は使用しません。アプリケーションのパフォーマンス目標がこの方法のみでは実現できなければ、追加のハードウェアが必要になる場合もあります。
SSLを効果的に使用できるようにアプリケーションを設計します。セキュアな操作をグループ化して、SSLセッションおよびSSL接続を再利用します。
可能な場合は永続的な接続を使用して、SSLセッションの再利用のコストを最小限に抑えます。
セッション・キャッシュのタイムアウト値をチューニングします(ssl.confのSSLSessionCacheTimeoutディレクティブ)。SSLセッション・キャッシュを維持するコストと、新しいSSLセッションを確立するコストの間には、トレードオフが存在します。一般に、保護されたビジネス・プロセス、つまり概念的にグループ化されたSSL交換は、セッション作成を複数回行わずに完了させる必要があります。SSLSessionCacheTimeout属性のデフォルト値は300秒です。アプリケーションの使い勝手をテストして、この設定のチューニングに役立ててください。
大量のデータがSSLで保護されている場合、使用されている暗号スイートに細心の注意を払ってください。暗号スイートは、ssl.confで指定されているSSLCipherSuiteディレクティブによって制御します。低いレベルのセキュリティでも許容される場合は、小さいサイズの鍵を使用する、暗号強度の低いプロトコルを使用します(これによってパフォーマンスが大幅に向上します)。目的のセキュリティ・レベルを確保するために使用可能な暗号スイートをそれぞれ使用してアプリケーションをテストし、最適な暗号スイートを見つけます。
前述の考慮事項に配慮しても、SSLが引き続きアプリケーションのパフォーマンスおよびスケーラビリティのボトルネックとなる場合は、ハードウェア・クラスタに複数のOracle HTTP Serverインスタンスをデプロイするか、SSLアクセラレータ・カードを使用することを検討してください。
OracleASポート・トンネリングが構成されている場合、リクエストはすべてOracleASポート・トンネリング・インフラストラクチャを経由して処理されます。したがって、OracleASポート・トンネリングは、Oracle HTTP Serverによるリクエスト処理のパフォーマンスおよびスケーラビリティ全体に大きく影響します。
実行されるOracleASポート・トンネリング・プロセスの数を除き、OracleASポート・トンネリングのパフォーマンスは自動的にチューニングされます。唯一可能なパフォーマンス制御は、より多くのOracleASポート・トンネリング・プロセスを開始することです。これにより、使用可能な接続の数が増え、システムのスケーラビリティが向上します。
OracleASポート・トンネリング・プロセスの数は、必要とされる可用性の度合いや期待される接続数に基づきます。プロセスを追加するたびに、DMZとイントラネットの間のファイアウォールを介して新しいポートをオープンする必要があるため、この数を自動的に決定することはできません。オープンしたポートより多くのプロセスは開始できません。また、オープンしたポートより少ないプロセスも好ましくありません。この場合、プロセスの割り当てられないポートが存在することになります。
OracleASポート・トンネリングのパフォーマンスを測定するには、OracleASポート・トンネリング・インフラストラクチャを経由するサーブレット・リクエストのリクエスト時間を調べます。OracleASポート・トンネリングを使用した場合と使用しない場合のレスポンス時間を比較して、OracleASポート・トンネリングによってパフォーマンス要件が満たされているかどうかを確認する必要があります。
|
関連項目: OracleASポート・トンネリングの構成の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。 |
次のヒントを利用すると、Oracle HTTP Serverのパフォーマンスに関する問題の回避やデバッグが可能になります。
問題の主な原因となっている箇所を集中的にチューニングできるよう、サーバーがどこでリソースを消費しているかを把握することが重要です。システムを構成する際には、受信リクエストの何パーセントが静的なもので何パーセントが動的なものかを知っておくと役立つ場合があります。
一般に、動的なページは生成のコストが余計にかかるため、動的なページのチューニングに時間をかけてください。また、アプリケーションの監視およびチューニングを行うことで、カタログ・データなどの動的に生成されたコンテンツの多くがキャッシュ可能であり、リソースの使用量を大幅に節減できることも明らかになります。
データに外れ値があると、状態を正確に反映していない結果が生成されます。このような状況は、起動時に起こることがあります。簡単な例をシミュレーションしてみましょう。PL/SQLのHello, Worldアプリケーションを約30秒間実行したとします。結果を調べてみると、処理はすべてmod_plsql.c内で次のように行われていました。
/ohs_server/ohs_module/mod_plsql.c handle.maxTime: 859330 handle.minTime: 17099 handle.avg: 19531 handle.active: 0 handle.time: 24023499 handle.completed: 1230
ここで、このモジュールのhandle.maxTimeがhandle.avgよりはるかに大きい点に注意してください。これはおそらく、最初のリクエストを受信したときに、データベース接続をオープンする必要があるためです。その後のリクエストは、すでに確立された接続を利用できます。この場合、PL/SQLモジュールの平均サービス時間をより正確に推定するには、handle.maxTime値を増加させていたデータベース接続のオープンにかかる時間を除外して、次のように平均を計算しなおします。
(time - maxTime)/(completed -1)
例:
(24023499 - 859330)/(1230 - 1) = 18847.98
Apache 2.2をベースとする現行のOracle HTTP Serverは、Apache 1.3をベースとしていた旧リリースのOracle HTTP Serverと比べて、リクエストの処理方法の点でアーキテクチャがわずかに異なっています。
新しいアーキテクチャでは、Oracle HTTP Serverは各モジュールのロード済のサービス関数を(httpd.confファイルで定義されている順に)リクエストが処理されるまで呼び出します。つまり、各モジュールのサービス関数を呼び出す際には、サービスが承認されたか却下されたかを認識するためのコストが発生することになります。
アーキテクチャがこのように変更されたため、httpd.confファイルの中では、最も使用頻度の高いモジュールを他のモジュールより前に配置することを検討してください。
Oracle HTTP Serverに直接デプロイされ、デフォルト・ハンドラによって処理される静的ページのリクエストは、デフォルト・ハンドラが呼び出されるまでに、すべてのモジュールを通過する必要があります。このプロセスはリクエストのパフォーマンスに影響を与える可能性があるため、デプロイ済のアプリケーションで必要とされるモジュールのみを有効にすることを検討してください。たとえば、デプロイ済のアプリケーションでmod_plsqlが使用されない場合は、パフォーマンスを確保するためにmod_plsqlを無効にします。
また、URLの変換段階でなんらかの処理を行うためにフックを登録するモジュールがいくつかあります。これも、リクエスト処理時間のコストが増加する原因となります。たとえば、specwebベンチマークによると、mod_securityを有効にした場合、1トランザクションにつきCPUコストが約10%増加します。この場合も、デプロイ済のアプリケーションで必要とされるモジュールのみを有効にして、CPU時間を節約してください。
使用可能なファイル・ディスクリプタの不足は、必ずしも簡単にオペレーティング・システムのファイル・ディスクリプタ制限まで遡れない様々な症状の原因になる可能性があります。ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するユーザーに対してオペレーティング・システムの強い制限を構成します。構成すると、OHSはオペレーティング・システムの制限と一致するように弱い制限を調整します。
ファイル・ディスクリプタ制限の構成は、プラットフォーム固有です。詳細は、オペレーティング・システムのドキュメントを参照してください。次のコード例は、Linuxのコマンドを示しています。
APACHECTL_ULIMIT=ulimit -S -n `ulimit -H -n`
この制限は、パッチ・セットの適用後に再構成する必要があります。
