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 HTTP Serverの最適化のテクニックについて説明します。
この章には、次の項が含まれています。
アプリケーション・サーバーを構成するために、Oracle HTTP Serverではhttpd.confのディレクティブを使用します。この構成ファイルでは、同時に処理できるHTTPリクエストの最大数、ロギングの詳細、制限およびタイムアウトを指定します。
表6-1に、パフォーマンスに大きな影響を与えるディレクティブをまとめます。
KeepAliveディレクティブのデフォルトの設定は、次のとおりです。
KeepAlive on MaxKeepAliveRequests 100 KeepAliveTimeOut 15
これらの設定により、永続的な接続の欠点を最小限に抑えながら、利点を活用できるように、接続当たりのリクエストおよびリクエスト間の時間が設定されています。ご使用のシステムでこれらの値を設定する際は、ご使用のシステムのユーザー数と作業内容を考慮する必要があります。たとえば、ユーザー数は多いが、ユーザーが送信するリクエストが小さく頻度が低い場合は、KeepAliveディレクティブのデフォルト設定値を小さくするか、またはKeepAliveをoffに設定します。ユーザー数が少なく、サイトに頻繁にアクセスする場合は、設定値を大きくします。
この項では、ロギングのタイプ、ログ・レベル、さらにロギングの使用によるパフォーマンスへの影響について説明します。
静的ページのリクエストの場合、デフォルト・フィールドのアクセス・ロギングにより、パフォーマンス・コストが2〜3%増加します。
デフォルトでは、HostNameLookupsディレクティブはOffに設定されています。サーバーにより、着信リクエストのIPアドレスがログ・ファイルに書き込まれます。HostNameLookupsがOnに設定されると、サーバーは各リクエストのIPアドレスに関連付けられたホスト名をインターネット上のDNSシステムに問い合せ、ホスト名をログに書き込みます。
オラクル社のテストで、HostNameLookupsをOnに設定したところ、パフォーマンスは約3%（最良の場合）低下しました。サーバーの負荷とご使用のDNSサーバーへのネットワーク接続状況により、DNS検索のパフォーマンス・コストが高くなる可能性があります。ログ中にリアル・タイムでホスト名が必要な場合以外は、IPアドレスでログを行うことをお薦めします。
UNIXシステムでは、$ORACLE_HOME/Apache/Apache/bin/ディレクトリにあるlogresolveユーティリティを使用して、オフラインでIPアドレスをホスト名に解決できます。
サーバーにより、エラー・ログに異常なアクティビティが記録されます。ErrorLogおよびLogLevelディレクティブにより、ログ・ファイルと、記録されるメッセージの詳細レベルを指定します。デフォルトのレベルはwarnです。負荷のかかったシステムにおける静的ページのパフォーマンスでは、warn、infoおよびdebugのレベルで違いはありませんでした。
動的リソースを使用するリクエストの場合（たとえばmod_osso、mod_plsql、またはmod_oc4jを使用するリクエスト）、debugレベルなどのより高位のデバッグ・レベルの設定によりパフォーマンス・コストが発生します。
この項には、次の項目が含まれています。
Secure Sockets Layer（SSL）は、Netscape社によって開発されたプロトコルで、インターネット上での認証と暗号化による通信を提供します。概念的には、SSLはプロトコル・スタックのアプリケーション層とトランスポート層の中間に存在します。SSLは技術的にはアプリケーションに依存しないプロトコルですが、HTTPを介したセキュリティの提供が標準となった現在では、すべての主要なWebブラウザでSSLがサポートされています。
SSLは、Webベースのアプリケーションのレスポンス能力とスケーラビリティの両方でボトルネックとなる可能性があります。SSLが要求される場合、プロトコルのパフォーマンスに関する問題を慎重に考慮する必要があります。SSLプロトコルを使用する場合、特にセッションの作成および始動などのセッション管理が、最もパフォーマンス・コストのかかる部分です。
この項には、次のSSLパフォーマンス関連の情報が含まれています。
SSL接続が開始されると、クライアントとサーバー間のハンドシェイクに基づくセッションが発生します。これには暗号スイートのネゴシエーション、データ暗号化用の秘密鍵の交換、およびデジタル署名証明書を介したサーバーおよび任意のクライアントの認証が含まれます。
SSLのセッション状態がクライアントとサーバー間で開始された後は、サーバーによってセッション状態を保存および再利用できるので、後続のSSLリクエストでセッションを確立しハンドシェイクを作成する必要がなくなります。Oracle HTTP Serverでは、デフォルトでクライアントのSSL（Secure Sockets Layer）セッション情報をキャッシュします。セッション・キャッシュを使用すると、待ち時間が長いのはサーバーへの最初の接続時のみになります。
httpd.confのSSLSessionCacheTimeoutディレクティブにより、サーバーで保存されたSSLセッションを保持する期間を指定します（デフォルトは300秒です）。セッション状態は、指定した時間の経過後に使用されない場合は廃棄されます。そして、後続のSSLリクエストでは新しいSSLセッションを確立し、もう一度ハンドシェイクを開始する必要があります。SSLSessionCacheディレクティブでは、SSLセッション情報の保存場所を指定します。デフォルトの保存場所は、UNIXシステムでは$ORACLE_HOME/Apache/Apache/logs/ディレクトリで、Windowsシステムでは%ORACLE_HOME%¥Apache¥Apache¥logs¥です。保存されたセッション・キャッシュ・ファイルは、複数の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接続とともに維持されます）。
SSLを使用するほとんどのアプリケーションでは、データ暗号化のコストは、SSLセッション管理と比較して小さくなります。暗号化コストが著しく発生するのは、暗号化されたデータのボリュームが大きい場合です。そのような場合、データ暗号化アルゴリズムとSSLセッションに選択した鍵のサイズはきわめて大きくなります。
通常、セキュリティ・レベルとパフォーマンス間にはトレードオフが発生します。たとえば、最新のプロセッサでは、RSAはRC4暗号化が1出力バイト当たり8〜16の処理に対応すると見積っています。通常のDES暗号化ではRC4のおよそ8倍のオーバーヘッドが発生し、Triple-DESではDESのおよそ25倍のオーバーヘッドが発生します。ただし、Triple-DESを使用している場合、暗号化コストはほとんどのアプリケーションで顕著ではありません。Oracle HTTP Serverでは、これら3つの暗号スイートおよびその他の暗号スイートがサポートされています。
Oracle HTTP Serverでは、httpd.confで指定されているSSLCipherSuite属性に基づき、クライアントと暗号スイートをネゴシエートします。
次の推奨事項は、Oracle HTTP ServerをSSLとともに使用する場合のパフォーマンス要件を決定する際に役立ちます。
httpd.confのSSLSessionCacheTimeout属性）。SSLセッション・キャッシュを維持するコストと、新しいSSLセッションを確立するコストの間に、トレードオフが存在します。一般に、保護されたビジネス・プロセスまたはSSL交換の概念的なグループ化は、複数のセッションを作成せずに完了する必要があります。SSLSessionCacheTimeout属性のデフォルト値は、300秒です。アプリケーションの活用性をテストして、この設定のチューニングに役立ててください。
httpd.confで指定されているSSLCipherSuiteディレクティブによって、暗号スイートを制御します。より低いレベルのセキュリティが許容される場合、より小さいサイズの鍵を使用する暗号強度の低いプロトコルを使用します（これによってパフォーマンスが大幅に改善します）。最後に、目的のセキュリティ・レベルを確保するために使用可能な暗号スイートをそれぞれ使用してアプリケーションをテストし、最もパフォーマンスの高い暗号スイートを検証します。
OracleAS Port Tunnelingが構成されている場合、すべてのリクエストはOracleAS Port Tunnelingインフラストラクチャを経由して処理されます。つまりOracleAS Port Tunnelingは、Oracle HTTP Serverのリクエスト処理に関わるパフォーマンスおよびスケーラビリティ全体に大きく影響します。
実行されるOracleAS Port Tunnelingプロセスの数を除き、OracleAS Port Tunnelingのパフォーマンスは自動的に調整されます。唯一可能なパフォーマンス制御は、より多くのOracleAS Port Tunnelingプロセスを開始することです。これにより、使用可能な接続の数が増え、システムのスケーラビリティが増大します。
OracleAS Port Tunnelingプロセスの数は、プロセスが必要とされる度合いや期待される接続数に基づきます。プロセスを追加するたびに、DMZとイントラネット間のファイアウォールを介して新しいポートをオープンする必要があるので、この数を自動的に決定することはできません。オープンしたポートよりも多くのプロセスは開始できません。また、オープンしたポートよりも少ないプロセスも好ましくありません。この場合、プロセスが割り当てられないポートが存在することになります。
OracleAS Port Tunnelingのパフォーマンスを測定するには、OracleAS Port Tunnelingインフラストラクチャを経由するサーブレット・リクエストのリクエスト時間を判断します。OracleAS Port Tunnelingを使用した場合とそうでない場合のOracle Application Serverインスタンスのレスポンス時間を比較して、OracleAS Port Tunnelingによってパフォーマンス要件が満たされているかどうかを確認する必要があります。
次のヒントを利用すると、Oracle HTTP Server（OHS）のパフォーマンスの潜在的な問題の回避やデバッグが可能になります。
サーバーがどこでリソースを消費しているのかを把握すれば、チューニングに対する労力を問題の主な原因となっている箇所に集中できます。システムを構成する際は、着信リクエストの何パーセントが静的なもので何パーセントが動的なものかを知ることが役に立つ場合があります。
一般的に、生成のコストが余計にかかることの多い動的なページのチューニングに時間をかけることが多いようです。アプリケーションの監視とチューニングを行うことで、カタログ・データなどの動的に生成されたコンテンツの多くがキャッシュ可能であり、リソースの使用量を大幅に節減できることも明らかになります。
状況によっては、Oracle Containers for J2EE（OC4J）のリクエストの平均処理時間と、ユーザーが経験する平均レスポンス時間に大きな開きがあるかもしれません。OC4Jでの実際の処理に時間が費やされているのでなければ、おそらく転送に時間がかかっています。
OC4Jのリクエスト処理時間と平均レスポンス時間の差が大きい場合は、「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
|
 Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|