| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
この章では、Oracle Web Cacheのパフォーマンスを改善するためのガイドラインを示します。
Oracle Web Cacheは、Web層で使用されるコンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)です。Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュ機能は、頻繁にアクセスされるURLをメモリーに格納することによって、Oracle Fusion Middlewareで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。また、Oracle HTTP ServerやOracle WebLogic Serverといった任意のWebサーバーまたはアプリケーション・サーバーで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性も改善できます。
詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
効率的なOracle Web Cacheのパフォーマンス・チューニングを行うには、まずその使用方法と一般的なパフォーマンスの問題について十分に理解します。Oracle Adaptive Access Managerのチューニングを開始する前に、この項と、「主なパフォーマンス分野」で説明した推奨事項に目を通してください。
Oracle Web Cacheは、非常に強力なCPU 1つ、またはCPU 2つで、最適なパフォーマンスを発揮します。Oracle Web Cacheはメモリー内キャッシュであるため、CPUサイクルの制限をほとんど受けません。CPUを追加しても、パフォーマンスが大幅に向上することはありません。ただし、プロセッサの速度は重要なので、できるだけ高速なCPUを使用してください。Web Cacheが他のOracleアプリケーション・サーバー・コンポーネントや他のアプリケーションとシステムを共有している場合は、使用するCPUを増やします。
Oracle Web Cacheは割当て可能なメモリー量によって制限されることに注意してください。メモリーを増やすと、パフォーマンスおよびスケーラビリティが改善します。必要なメモリーの量の詳細は、第10.2.1.2項「メモリー構成」を参照してください。
Oracle Web Cacheには2つのプロセスがあります。1つは管理サーバー用、もう1つはキャッシュ・サーバー用です。
管理サーバー・プロセスは、Oracle Web Cacheの構成および監視に使用されます。このプロセスが消費するCPU時間はごくわずかです。ただし、Oracle Web Cache Managerで統計ページを表示する際、管理サーバー・プロセスは、キャッシュ・サーバー・プロセスに問い合せて、該当するメトリックを取得する必要があります。統計ページに頻繁にアクセスする、つまり統計ページのリフレッシュ頻度を高く設定すると、キャッシュ・サーバーのパフォーマンスに影響が出ることがあります。
キャッシュ・サーバー・プロセスは、3つのスレッドを使用します。1つ目はフロントエンド・アクティビティの管理用、2つ目はバックエンド・アクティビティの管理用、3つ目はリクエストの処理用です。
Oracle Web Cacheをコスト効率よく使用するには、大量のメモリーを搭載した、高速な2 CPUのコンピュータ上で実行します。様々なデプロイメント・シナリオの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
複数のOracle Web Cacheインスタンスが存在するWebサイトでは、各インスタンスをキャッシュ・クラスタの一部、またはスタンドアロン・インスタンスとして別の2 CPUノードにインストールすることを検討してください。Oracle Web Cacheインスタンスが別のノードにある場合、特にネットワーク・スループットの点で、オペレーティング・システムの制限を受けることが少なくなります。たとえば、2つの別々の2 CPUノード上に2つのキャッシュがある場合、1つの同じ4 CPUノード上に2つのキャッシュがある場合よりもオペレーティング・システムの制限を受けにくくなります。
他のリソースがCPUの使用をめぐってOracle Web Cacheと競合している場合、必要なCPUの数を決める際には、もちろんこれらのリソースの要件を考慮してください。最もよいのはOracle Web Cacheを別のノードに分けることですが、Oracle Web CacheをアプリケーションWebサーバーの残りの部分と同じノード上で実行したとしても、パフォーマンス上の大きな利点を得ることができます。
スワッピングによってドキュメントがキャッシュから出し入れされるのを回避するには、キャッシュ用に十分なメモリーを構成します。一般に、Oracle Web Cacheのメモリー量(最大キャッシュ・サイズ)は512MB以上に設定する必要があります。アプリケーションのメモリー要件は、ドキュメント・サイズ、ドキュメント数、返されるHTTPヘッダーの数、ESIが存在するかどうかなどの要因によって変わります。必要なメモリーの最大量を厳密に見積るには、次に示す式を使用します。アプリケーションでESIを使用する場合は、TotalDocsおよびAvgDocSizeを計算する際に、テンプレートとドキュメント・フラグメントをすべて含める必要があります。
推定キャッシュ・サイズ(バイト) = 1.25 *(TotalDocs * ((AvgDocSize/8192+1) *8192+ 16384))
0.25は、実行時のメモリー使用率を表します。Web Cacheのアクション制限は、デフォルトでWeb Cacheの最大サイズより5%小さく設定されます。また、キャッシュできないアクセス・ミスを最適化するために、合計キャッシュ・サイズの5%が割り当てられます。
TotalDocsは、Web Cacheに格納するドキュメントの総数を表します。
AvgDocSizeの意味は、その名のとおりです。
式から返されるバイト単位の推定キャッシュ・サイズを変換することを念頭に置いてください。
前述のメモリー計算式を、実際に測定されたメモリー使用量に対して検証したところ、次の表に示すように、きわめて近い結果が得られました。
| キャッシュされた数 | ドキュメント・サイズ | 測定されたキャッシュ | 式から求めた結果 |
|---|---|---|---|
|
ドキュメント |
バイト |
サイズ(MB) |
サイズ(MB) |
|
3300.00 |
102400 |
499.61 |
499.51 |
|
5525.00 |
51200 |
499.27 |
499.08 |
|
11050.00 |
51200 |
998.54 |
998.17 |
|
6600.00 |
102400 |
999.22 |
999.02 |
|
13200.00 |
102400 |
1998.44 |
1998.05 |
|
22100.00 |
51200 |
1997.07 |
1996.34 |
|
3300.00 |
102400 |
499.61 |
499.51 |
Oracle Web Cacheを起動したとき、キャッシュは空です。監視を有効なものとするため、キャッシュが満杯になっていることを確認してください。つまり、指定した数のドキュメントがキャッシュされるように、キャッシュが十分な数のリクエストを受け取っていることを確認します。
Oracle Web Cacheの「統計」ページ(「監視中」→「Web Cache統計」)には、現在のメモリー使用量、最大のメモリー使用量、および現在Oracle Web Cacheに存在するドキュメントの総数についての情報が表示されます。キャッシュ概要表の次のメトリックに注意してください。
「キャッシュ内のドキュメントのサイズ」は、キャッシュの現在の論理サイズを示します。これは、キャッシュ内の有効なドキュメントのサイズです。たとえば、3KBと50KBの2つのドキュメントがキャッシュに格納されている場合、「キャッシュ内のドキュメントのサイズ」は、2つのサイズを合計した53KBです。
「構成済の最大キャッシュ・サイズ」は、「リソース制限」ページで指定した最大キャッシュ・サイズを示します。
「現在の割当て済メモリー」には、キャッシュの物理サイズが表示されます。これは、キャッシュの保存および処理用にOracle Web Cacheによって割り当てられたデータ・メモリーの量です。この数は、オペレーティング・システム統計の示すプロセス・サイズより常に小さくなります。これは、Oracle Web Cacheプロセスが他のユーザー・プロセスと同様に、指示記憶域、スタック・データ、スレッド、ライブラリ・データといった他の方法でもメモリーを消費するためです。
現在のアクション制限は、構成済の最大キャッシュ・サイズの95%です。通常、この数は現在の割当て済メモリーより大きくなります。
現在の割当て済メモリーが現在のアクション制限より大きい場合、Oracle Web Cacheは割り当てられているが使用されていないメモリーを使用し始めます。また、メモリーを解放するためにガベージ・コレクションを開始する場合もあります。ガベージ・コレクションの実行中、Oracle Web Cacheは、使用頻度が低く、有効性の低いドキュメントをキャッシュから削除し、頻繁に使用される有効なドキュメントはそのまま保持します。これにより、最大キャッシュ・サイズを超えずに、新しいHTTPレスポンス用の領域を確保することができます。
現在の割当て済メモリーが現在のアクション制限に近いか、それより大きい場合は、最大キャッシュ・サイズを増やし、スワッピングによってドキュメントがキャッシュから出し入れされるのを回避します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheシステム・コンポーネントのプロパティの指定に関する項を参照してください。
ほとんどのUNIXプラットフォームでは、クライアント接続ごとに別々のファイル・ディスクリプタが必要です。Oracle Web Cacheサーバーは、起動時に最大数のファイル・ディスクリプタを確保しようとします。root権限がある場合は、この数を増やすことができます。たとえば、Linuxオペレーティング・システムでは、/etc/security/limits.confでOracle Web Cacheのユーザー・ファイル・ディスクリプタ制限を変更することで、ファイル・ディスクリプタの最大数を増やすことができます。
たとえば、ユーザーWC_USERに4092の接続を許可するには、/etc/security/limits.confファイルに次のエントリを追加します。
WC_User soft nofile 4092 WC_User hard nofile 4092
/etc/sysctl.confファイルのfs.file-maxパラメータを増やして、ホスト上のすべてのプロセスが適切な数のファイル・ディスクリプタを使用できるようにしてください。
Solarisオペレーティング・システムでは、rlim_fd_maxパラメータを設定することで、ファイル・ディスクリプタの最大数を増やすことができます。webcachedがrootとして実行されていないと、Oracle Web Cacheサーバーは起動に失敗し、エラー・メッセージがログに記録されます。
Windowsでは、ファイル・ハンドルおよびソケット・ハンドルの数(ページングされたプールおよびページングされていないプールのサイズ)は、使用可能なカーネル・リソースのみによって制限されます。ただし、アクティブなTCP/IP接続の数は、システムでオープン可能なTCPポートの数によって制限されます。
接続の確立の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のリソース制限およびネットワークしきい値の設定に関する項を参照してください。
この項では、Oracle Web Cacheのチューニングに関する基本的な考慮事項について説明します。チューニングに関する次の推奨事項が含まれます。
Oracle Web Cacheを使用する際は、スループットの負荷に対応するための十分なネットワーク帯域幅が各システムにあることを確認してください。そうでないと、ネットワークが飽和状態になっても、Oracle Web Cacheの容量にまだ余裕があるという状況が発生します。たとえば、アプリケーションで1秒間に100メガビット以上のデータが生成される場合、10/100 Megabit Ethernetでは飽和状態になる可能性があります。
ネットワークが飽和状態になった場合は、10/100 Megabit Ethernetではなく、Gigabit Ethernetを使用することを検討してください。Gigabit Ethernetは、ネットワークでの衝突、再送信および帯域幅の不足を回避するための最も効率的なデプロイメント・シナリオを提供します。さらに、2つの異なるネットワーク・カードを使用することも検討してください。1つは受信クライアント・リクエスト用、もう1つはキャッシュからアプリケーションWebサーバーへのリクエスト用です。
ネットワーク帯域幅の使用状況を示すネットワーク監視ユーティリティを使用します。ネットワークが十分に活用されておらず、スループットが予想より低い場合は、CPUが飽和状態に達していないかを確認してください。
Oracle Web Cacheサーバーの最大接続数制限には、妥当な数を指定することが重要です。設定した数が大きすぎると、パフォーマンスに影響を与え、レスポンス時間が長くなります。設定した数が小さすぎると、処理できるリクエストの数が減ります。レスポンス時間と同時に処理するリクエストの数のバランスを取ってください。
妥当な数を決定するには、次の要因を考慮します。
ある時点で同時に処理するクライアントの最大数。
ドキュメントの平均サイズと1ドキュメント当たりの平均リクエスト数。
ネットワーク帯域幅。一度に送信できるデータの量は、ネットワーク帯域幅によって制限されます。
キャッシュ・ミスの割合。キャッシュ・ミスは、アプリケーションWebサーバーに転送されます。これらのリクエストは、ネットワーク帯域幅をさらに消費します。その結果、キャッシュ・ミスとなったリクエストの割合が高い場合は特に、レスポンス時間が長くなります。
ドキュメントの処理速度。ドキュメントの処理速度を測定するには、ttcpやLoadRunnerなどのネットワーク監視ユーティリティを使用します。
キャッシュ・クラスタ環境がある場合のキャッシュ・クラスタ・メンバーの容量。容量は、他のキャッシュ・クラスタ・メンバーからの着信接続の数を表しています。クラスタ・メンバーの容量は、Oracle Web Cache Managerの「クラスタリング」ページ(「プロパティ」→「クラスタリング」)を使用して設定します。
|
警告: 前述の値は、無理に大きな値に設定しないでください。Oracle Web Cacheでは、メモリーなどの一部のリソースが各接続用に確保されます。これらの値を変更すると、パフォーマンスに悪影響を与える可能性があります。 |
オペレーティング・システムやOracle Web Cacheなどに付属している様々なツールを使用して、最大接続数を決定します。たとえば、netstat-aコマンドを使用すると、確立されている接続の数を確認できます。また、ttcpユーティリティでは、ドキュメントの処理速度を測定できます。Oracle Web Cache Managerには、ヒットおよびミスの統計が表示されます。
着信接続の最大数を設定する手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheシステム・コンポーネントのプロパティの指定に関する項を参照してください。
ネットワーク接続数に加えて、Oracle Web Cache、アプリケーションWebサーバー、およびオペレーティング・システムのその他のネットワーク関連パラメータもレスポンス時間に影響を与えます。ほとんどの場合、デフォルトの設定で十分です。
レスポンス時間が長い場合は、この項の説明に従って、接続に影響を与えるOracle Web Cache、アプリケーションWebサーバー、およびオペレーティング・システムのパラメータをチューニングしてください。
Oracle Web Cacheについては、次の設定の値を確認します。
キープ・アライブのタイムアウト
Oracle Web Cacheがブラウザにレスポンスを送信した後、ネットワーク接続をオープンしておく時間。キープ・アライブを使用すると、HTTPクライアントは同じネットワーク接続を使用して、複数のリクエストをOracle Web Cacheに送信することができます。デフォルトでは、接続は5秒間オープンのままになります。これは通常、ブラウザが同じ接続を使用して後続のリクエストをOracle Web Cacheへ送信するのに十分な時間です。
ブラウザとOracle Web Cacheとの間のネットワークが遅い場合は、タイムアウトを増やすことを検討してください。まず10秒で、次に20秒で試し、最大30秒まで増やします。
次のエラーが表示された場合は、Oracle Web Cacheの最大着信接続数を増やすか、「キープ・アライブのタイムアウト」を小さくします。
11313: The cache server reached the maximum number of allowed incoming connections. Listening is temporarily suspended.
ストレス・テスト中など負荷が大きい場合に、クライアントがリクエストを1つ送信すると接続が切れる状態が続くときは、「キープ・アライブのタイムアウト」を0に設定します。この値の場合、Oracle Web Cacheはリクエストが完了するとすぐに接続をクローズし、リソースを解放します。
「キープ・アライブのタイムアウト」の値は、ネットワーク・タイムアウト・ページ(「プロパティ」→「ネットワーク・タイムアウト」)で設定します。
オリジン・サーバー・タイムアウト
アプリケーションWebサーバーがOracle Web Cacheへのレスポンスを生成するための時間。アプリケーションWebサーバーまたはプロキシ・サーバーがこの時間内にレスポンスを生成できない場合、Oracle Web Cacheはブラウザにネットワーク・エラー・ページを送信します。
通常、この値は、アプリケーションWebサーバーで処理された最も遅いドキュメントのレスポンス時間と一致させる必要があります。値が小さすぎると、実行時間の長いリクエストはレスポンスが完了する前にタイムアウトになります。値が大きすぎると、アプリケーションWebサーバーがなんらかの理由でハングしたときに、Oracle Web Cacheが別のアプリケーションWebサーバーにフェイルオーバーするまで時間がかかります。
この値は、ネットワーク・タイムアウト・ページ(「プロパティ」→「ネットワーク・タイムアウト」)で設定します。
アプリケーションWebサーバーについては、アプリケーションWebサーバーの構成ファイル(httpd.conf)で次の設定の値を確認します。(次に示すパラメータの名前はOracle HTTP Server固有のものです。)
KeepAlive
永続的な接続を許可するかどうか。永続的な接続を使用すると、クライアントは同じ接続を通じて複数の連続したリクエストを送信できます。
KeepAliveが有効になっていることを確認してください。これにより、接続を一度確立すれば、同じクライアントからの後続のリクエストを受信できるよう接続がオープンのままになるので、パフォーマンスが向上します。
KeepAliveTimeout: 同じクライアントからの次のリクエストを待って接続をオープンしておく時間。リクエストが主にOracle Web Cacheからの場合、この値はかなり大きく設定できます。妥当な値は30秒です。
MaxKeepAliveRequests: 永続的な接続の間に許可するリクエストの最大数。0に設定すると、リクエストは無制限に許可されます。
MaxClients: アプリケーションWebサーバーに同時に接続できるクライアントの最大数。
KeepAliveがアプリケーションWebサーバーに対して有効になっている場合、必要な同時httpdサーバー・プロセスが増える可能性があります。また、MaxClientsディレクティブを大きな値に設定することが必要になる場合もあります。
クライアント・リクエストのレスポンス時間が短い場合は、MaxClientsを小さい値に設定することで、パフォーマンスを改善できる可能性があります。ただし、MaxClientsの値に達すると、プロセスをそれ以上作成できなくなるため、他のリクエストが失敗します。アプリケーションWebサーバーのMaxClients制限には、Oracle Web Cache Managerで設定したアプリケーションWebサーバーの容量以上の値を設定してください。
オペレーティング・システムについては、TCPの待機時間設定を確認します。この設定は、オペレーティング・システムがポートを保持し、新しい接続がその同じポートを使用できないようにする時間を制御します。
Linuxオペレーティング・システムでは、/proc/sys/net/ipv4/tcp_fin_timeoutの値を確認します。Solarisオペレーティング・システムでは、次のコマンドを使用してtcp_time_wait_intervalの設定を確認します。
ndd -get /dev/tcp tcp_time_wait_interval.
Windowsでは、次のレジストリ・キーのTcpTimeWaitDelayの値を確認します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
通常、この設定が問題となるのは、ストレス・テスト中に、1つのクライアント・コンピュータから常に多くのTCP/IP接続をオープンする場合のみです。そのような状況では、TCPの待機時間設定を小さくします。実際のデプロイメントでは、単一クライアントが多数の接続を生成することはほとんどないので、これが問題になることはまれです。
キャッシュ・ヒットとは、キャッシュに保存されているドキュメントで対応可能な、Webブラウザによるリクエストです。キャッシュ・ミスとは、キャッシュに保存されているドキュメントでは対応できず、アプリケーションWebサーバーに転送する必要のある、Webブラウザによるリクエストです。
キャッシュ・ミスに対するキャッシュ・ヒットの比率が低い場合は、次の方法でキャッシュ・ヒット率を上げることを検討してください。
CookieおよびURLパラメータを使用してキャッシュ・ヒット率を上げます。
Oracle Web Cacheでは、Cookieまたはヘッダーのリクエストに基づいて、同じURLを持つドキュメントの異なるバージョンをキャッシュできます。この機能を使用するには、ドキュメントを区別するCookieまたはヘッダーの作成など、簡単な変更をアプリケーションに加える必要があります。
アプリケーションに無意味なURLパラメータが含まれているために、同じコンテンツが異なるURLで表される場合があります。完全なURLでドキュメントをキャッシュすると、キャッシュ・ミスに対するキャッシュ・ヒットの比率は非常に低くなります。区別の不要なURLパラメータ値を無視するようOracle Web Cacheを構成すれば、単一のドキュメントが異なるURLに対してキャッシュされるようになり、キャッシュ・ヒット率が大幅に向上します。
一連のドキュメントのコンテンツがほとんど同一の場合もあります。たとえば、ドキュメント内のハイパーリンクが、セッション固有の異なる値を持つ同一のURLパラメータで構成されている場合や、ウェルカム・メッセージ、ショッピング・カートの合計などのパーソナライズされた文字列がドキュメントのテキストに含まれている場合などです。埋込みURLパラメータやパーソナライズされた文字列のプレースホルダを含むドキュメントを1つ保存しておき、そのドキュメントをクライアントに提供する際、正しい値をプレースホルダに動的に代入するように、Oracle Web Cacheを構成できます。
複数のバージョンのドキュメント、セッション、URLパラメータ値の無視、および単純なパーソナライズの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheの管理のスタート・ガイドを参照してください。
リダイレクションを使用してエントリ・ドキュメントをキャッシュします。
一般にセッションの確立を必要とする、使用頻度の高いサイトのエントリ・ドキュメント(/など)の場合、セッションが確立されると、そのドキュメントはセッションを持たないすべての新しいユーザーに対して、事実上キャッシュ不可になります。確立されたセッションを保持したまま、このドキュメントをキャッシュするには、次のいずれかを実行します。
すべての初期リクエストに対してセッションを確立して、使用頻度の高い実際のドキュメントにリダイレクトする、空白のドキュメントを作成します。使用頻度の高いドキュメントにリダイレクトされる後続のリクエストでセッションを指定すれば、そのドキュメントをキャッシュから取得できます。
JavaScriptを使用して、使用頻度の高いドキュメントに対するセッションCookieを設定します。
|
注意: セッションの確立を必要とするドキュメントのキャッシュ・ルールを構成する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のコンテンツのキャッシュおよび圧縮に関する項を参照してください。 |
可能な場合はページの部分的なキャッシュを使用します。
OracleAS Portalによって生成されるページなど、多くのWebドキュメントは、一意のキャッシュ・プロパティを持つフラグメントで構成されています。このようなページの場合、ページ全体をキャッシュするのは不可能です。ただし、Oracle Web Cacheには、Edge Side Includes (ESI)を使用してページを部分的にキャッシュする機能があります。ESIを使用すれば、各Webページをテンプレートと複数のフラグメントに分割し、それをテンプレートと下位レベルのフラグメントにさらに分割することができます。各フラグメントまたはテンプレートは個別に保存および管理され、リクエストに応じて基礎となるフラグメントからページ全体が組み立てられます。異なるテンプレートでフラグメントを共有できるため、共通のフラグメントが何度もキャッシュされてキャッシュ領域が無駄になることはありません。フラグメントを共有することで、フラグメントの期限が切れたときに必要な更新の回数も大幅に削減できます。
アプリケーションによっては、フラグメントを更新するほうが、ページ全体を更新するよりコストがかかりません。さらに、各テンプレートまたはフラグメントに、期限切れ、検証、無効化などの独自のキャッシュ・ポリシーを設定できます。そうすることで、キャッシュされないフラグメントやキャッシュされる期間の短いフラグメントがある場合にも、完全なWebページの各フラグメントが可能なかぎりキャッシュされます。
ESI変数を使用して、パーソナライズされたページのキャッシュ・ミスに対するキャッシュ・ヒットの比率を改善します。
パーソナライズされた情報がWebページに表示され、そのページが各ユーザーに固有のWebページになることがよくあります。たとえば、多くのWebページには、アプリケーション・セッションIDを埋め込んだハイパーリンクが何十、何百と含まれています。これを解決するには、変数を指定したESIページを作成します。変数は、リクエスト情報やレスポンス情報の様々な部分に解決できるため、テンプレートおよびフラグメントの一意性が大幅に軽減されます。その結果、キャッシュ・ミスに対するキャッシュ・ヒットの比率が向上します。
アプリケーションWebサーバーまたはキャッシュを正しく構成していない場合、レスポンス時間が予想より長くなることがあります。この項には、この章で説明した内容の大部分が要約されています。
アプリケーションWebサーバーのレスポンスが予想より遅い場合や、アプリケーションWebサーバーが容量に達したためにキャッシュからのリクエストに応答しない場合は、アプリケーションWebサーバーおよびOracle Web Cacheの設定を確認します。
まず、次の項目を確認します。
キャッシュ・ルール: 適切なオブジェクトをキャッシュしていることを確認します。使用頻度の高いオブジェクトをキャッシュする必要があるのに、実際にはキャッシュしていない、ということはありませんか。「ポピュラーなリクエスト」ページ(「監視中」→「ポピュラーなリクエスト」)を使用して、最もよく使用されているリクエストのリストを調べ、それらのオブジェクトがキャッシュされているかどうかを確認します。
キャッシュ・ルールの優先度ランキング: 頻繁にアクセスされるキャッシュ不可のドキュメントには、キャッシュ可能なドキュメントより高い優先度を指定します。頻繁にアクセスされるキャッシュ可能なドキュメントには、最も低い優先度を指定します。多数のルールを定義すると、キャッシュ・ルールの解析時に大量のリソースを消費する可能性がありますので注意してください。
圧縮: ネットワークがクライアントのボトルネックになっている場合、キャッシュ時にドキュメントを圧縮すると、圧縮されたドキュメントはサイズが小さくなるため、ネットワーク上の輻輳が軽減されます。
さらに、次の項目を確認します。
アプリケーションWebサーバーの構成、特にMaxClients、KeepAlive、KeepAliveTimeoutおよびMaxKeepAliveRequestsの設定。
アプリケーションWebサーバーのMaxClients制限には、Oracle Web Cache Managerで設定したアプリケーションWebサーバーの容量以上の値を設定してください。
Oracle Web Cache Managerの「オリジン・サーバー」ページ(「オリジン・サーバー、サイトおよびロード・バランシング」→「オリジン・サーバー」)を使用して設定したアプリケーションWebサーバーの容量。アプリケーションWebサーバーの容量を設定する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
アプリケーションWebサーバーの負荷がまだ予想より高い場合は、キャッシュがリクエストを処理できず、アプリケーションWebサーバーにルーティングされるリクエストが増えている可能性があります。Oracle Web Cache Managerで次のOracle Web Cache設定を確認します。
キャッシュ接続の数。「リソース制限」ページ(「プロパティ」→「リソース制限」)で、最大着信接続数を確認します。
キャッシュのメモリー・サイズ。「リソース制限」ページ(「プロパティ」→「リソース制限」)で、最大キャッシュ・サイズを確認します。
キャッシュ・クラスタの容量。キャッシュ・クラスタでは、クラスタの容量が小さすぎると、キャッシュが、指定された間隔でピア・キャッシュから所有コンテンツに対するレスポンスを受信できない可能性があります。その結果、リクエストはアプリケーションWebサーバーに送信されます。「クラスタリング」ページ(「プロパティ」→「クラスタリング」)で、容量を確認します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。
アプリケーションWebサーバーおよびOracle Web Cacheの設定は正しいが、レスポンス時間がまだ予想より長い場合は、システム・リソースを確認します。特に次の項目を確認してください。
ネットワーク帯域幅
CPU使用率
Oracle Web Cacheのチューニングに関する次の考慮事項は、ガイドとして提供されます。必ず各自のユースケース・シナリオを検討して、これらの構成をデプロイメントで使用できるかどうかを判断してください。
Oracle ADF Rich Clientアプリケーションに対するOracle Web Cacheのパフォーマンスを最適化するには、次の構成オプションを検討してください。
Oracle Web Cache Managerの「リソース制限」ページで「最大キャッシュ・サイズ」設定を構成した後、シミュレーションした負荷または実際の負荷を使用してキャッシュを監視し、実際に使用されるメモリーの量を確認します。メモリー使用量が増加した結果、ホストでディスクへのメモリー・スワッピングが発生していないかチェックします。メモリー・スワッピングが発生すると、パフォーマンスに影響が出ます。
すべてのサイトに適用されるパーソナライズおよび圧縮のルールには、次のものがあります。
イメージは、キャッシュするが圧縮は行いません。
CSSファイルは、すべてのリクエスト・タイプについてキャッシュと圧縮の両方を行います。
JSファイルは、すべてのリクエスト・タイプについてキャッシュと圧縮の両方を行います。
HTMLファイルは、キャッシュと圧縮の両方を行います。
SWFファイルは、キャッシュするが圧縮は行いません。
すべてのGETおよびPOSTSについて.jspxファイルを圧縮する(キャッシュはしない)ルールを追加します。
すべてのGETおよびPOSTSについて\.jspx.*$ファイルを圧縮する(キャッシュはしない)ルールを追加します。
すべてのリクエスト・タイプについてadw\.jspxを圧縮する(キャッシュはしない)ルールを追加します。
すべてのリクエスト・タイプについてprofiling.jsを圧縮する(キャッシュはしない)ルールを追加します。
キャッシュおよび圧縮のルールを設定する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のコンテンツのキャッシュおよび圧縮に関する項を参照してください。
