| Oracle Fusion Middleware mod_plsqlのためのユーザーズ・ガイド 11g リリース1（11.1.1） B56249-01 |
|
 戻る |
 次へ |
この章では、Oracle HTTP ServerでのPL/SQLのパフォーマンスを向上させるための方法について説明します。
この章の内容は、次のとおりです。
この項では、Oracle HTTP ServerでPL/SQLベースのWebアプリケーションのパフォーマンスを向上させるためのいくつかの方法について説明します。
表4-1に、データベース・アクセス記述子（DAD）のパラメータおよび設定の推奨事項を示します。デフォルトでは、これらのDADパラメータは、dads.confファイルに指定されます。このファイルは、UNIXシステムの場合、INSTANCE_HOME/config/OHS/ohs1/mod_plsqlディレクトリにあります。Windowsシステムの場合、デフォルトでは、INSTANCE_HOME\config\OHS\ohs1\mod_plsqlディレクトリにあります。このディレクトリのdads.READMEファイルには、DADパラメータについて詳細に説明されています。
表4-1 データベース・アクセス記述子（DAD）パラメータの推奨設定の概要
| パラメータ | 推奨設定 |
|---|---|
|
|
最高のパフォーマンスにするには、 デフォルト値: |
|
|
新しいDADには、 注意: データベースのHA構成では、接続文字列パラメータはLDAP検索を介して解決されるように設定することをお薦めします。 |
|
|
日本語や中国語などのマルチバイト・キャラクタ・セットの場合、 デフォルト値: |
|
|
このパラメータの値を増加すると、プールされたデータベース接続が、プール内で指定された時間、使用可能な状態を維持できます。 デフォルト値: 関連項目: 接続プールでの停止中のデータベース接続の検出に関する項 |
|
|
Oracleサポート・サービスからデバッグの目的で薦められないかぎり、 デフォルト値: |
|
|
接続プール内で停止中の接続を検出するためにmod_plsqlが使用するオプションを指定します。オプションは次のとおりです。
デフォルト値: 関連項目: 停止中のデータベース接続を検出するためのオプションの指定に関する項。 |
|
|
mod_plsqlにプールされた接続のテストに対するタイムアウトを（ミリ秒単位で）指定します。 デフォルト値: 関連項目: タイムアウト期間の指定に関する項。 |
|
|
PL/SQLベースのWebアプリケーションがリソースまたはメモリーをリークしない場合は、このパラメータをさらに高い値（5000など）に設定できます。 デフォルト値: 関連項目: プールされたデータベース・セッションのクローズおよび接続プーリングのヒントおよびOracle HTTP Server構成に関する項。 |
|
|
データベースのグローバリゼーション・サポートのパラメータと一致するように設定すると、Oracle Net Servicesでのキャラクタ・セット変換におけるオーバーヘッドを削減できます。 |
|
|
データベースがリリース8.1.7.2以上の場合、このパラメータを |
表4-2に、mod_plsqlのキャッシング・オプションと、そのオプションを説明している関連項目を示します。
表4-2 キャッシング・オプション
| オプション | 説明 |
|---|---|
|
期限方式 |
定期的に変わるコンテンツに対して、最高のパフォーマンスを提供します。 関連項目: 期限方式の使用に関する項 |
|
検証方式 |
不定期に変わるコンテンツに対して、良好なパフォーマンスを提供します。 関連項目: 検証方式の使用に関する項 |
|
システム・レベル・キャッシング |
システム上のすべてのユーザーに対して1つのコピーをキャッシュすることにより、パフォーマンスを向上させます。 関連項目: PL/SQLベースのWebアプリケーションでのシステム・レベルおよびユーザー・レベルのキャッシングに関する項 |
|
関連項目:
|
この項では、Oracle HTTP Serverがプロセス・ベースであるプラットフォームとスレッド・ベースであるプラットフォームの場合に当てはまるPL/SQLのパフォーマンス問題について説明します。プロセス・ベースのOracle HTTP Server（UNIXベースのプラットフォームで稼働するものなど）では、サーブレット、PL/SQL、静的ファイルを含め、すべてのタイプのHTTPリクエストを各プロセスで処理します。スレッド・ベースのOracle HTTP Server（Windowsベースのプラットフォームなど）では、Oracle HTTP Serverプロセスは1つしかなく、複数のスレッドがプロセス内にあり、個々のスレッドを使用してすべてのタイプのHTTPリクエストを処理できます。
|
注意: この章のいくつかの例では、PL/SQLベースのWebアプリケーションに適用されるパフォーマンスの最適化について言及していますが、そこでは、プラットフォーム間の相違、すなわちプロセス・ベースまたはスレッド・ベースのいずれであるかが重大な意味を持ちます。 |
mod_plsqlを使用する際、パフォーマンスおよびスケーラビリティに影響を及ぼす領域は次のとおりです。
PL/SQL Gatewayユーザーは、PL/SQLベースのWebアプリケーションを開発する際に、次の項目について考慮する必要があります。
データベース・アクセス記述子（DAD）の使用の管理
各Oracle HTTP Serverノードで使用されるDADの数を制限してください。
|
注意: 使用されていないDADがあっても、パフォーマンスに影響はありません。 |
ネストした表の使用
PL/SQLでは表を作成できます。PL/SQL表を作成するには、表の索引およびデータ型を持つ表を作成します。表の索引は、-2147483647〜+2147483647の2進整数です。この表索引オプションは、スパースと呼ばれ、顧客番号、従業員番号あるいはその他の便利な索引キーなど、重要な索引番号を使用できます。PL/SQL表は、大量データの処理に使用します。
PL/SQLには、TABLEおよびVARRAY（可変サイズ配列）のコレクション型があります。TABLEコレクション型は、ネストした表と呼ばれます。ネストした表は、サイズに制限がなく、スパースにできます。つまり、ネストした表内の要素はDELETEプロシージャを使用して削除できます。可変サイズ配列は、サイズに制限があり、データベースに格納される際に順序および添字を保持します。ネストした表のデータは、その表に関連付けられたシステム表に格納されます。可変サイズ配列は、アプリケーションがバッチ配列スタイルでデータを処理するバッチ操作に適しています。ネストした表は、ネストした表を格納表に格納して、各要素を格納表の行にマッピングすることで、問合せを効率的に行うことができます。
プロシージャ名のオーバーロードの慎重な使用
PL/SQLベースのWebアプリケーションでは、プロシージャ名のオーバーロード機能の使用に注意する必要があります。複数のプロシージャに異なる名前を付けて、プロシージャ名のオーバーロードを回避することが最良の方法です。
パラメータ・タイプの判別に著しいオーバーヘッドが発生するアプリケーションの再作成の検討
PL/SQLベースのWebアプリケーションでは、パラメータ・タイプ（スカラーや配列など）の詳細がURLから十分に提供されないプロシージャの実行におけるオーバーヘッドに注意する必要があります。このような場合、プロシージャを実行する最初の試みに失敗すると、mod_plsqlによって実行できるようにするためには、プロシージャ・シグネチャを記述する必要があります。
2パラメータ・スタイルの柔軟なパラメータの受渡しを利用するプロシージャの使用
プロシージャでは、4パラメータ・スタイルのパラメータの受渡しではなく、パフォーマンスの高い2パラメータ・スタイルの柔軟なパラメータの受渡しを利用します。
Oracle HTTP Serverで接続プーリングを構成する際、次の項目について考慮してください。
デフォルトの接続プーリングおよびPlsqlMaxRequestsPerSessionの設定値の使用
新しいデータベース接続の作成はコストの高い操作であるため、各リクエストが独自のデータベース接続をオープンおよびクローズしないことが最も重要です。最適な方法は、あるリクエストでオープンされたデータベース接続が、後続のリクエストで確実に再利用されるようにすることです。まれなケースですが、データベースへのアクセスが非常に少なく、パフォーマンスが重要な問題ではない場合には、接続プーリングは無効化してもかまいません。たとえば、管理者がサイトにアクセスして管理タスクを行うことがあまりない場合、管理アプリケーションへのアクセスに使用されるDADで、接続プーリングを無効化できます。接続プーリングを無効化するには、DADパラメータPlsqlMaxRequestsPerSessionを値1に設定します。
|
注意: PlsqlMaxRequestsPerSessionを値1に設定すると、使用可能なデータベース・セッション数が減り、パフォーマンスに影響を及ぼすことがあります。 |
UNIXシステムでは、プロセスが一度起動したら、そのプロセスが一定の時間起動した状態を維持するように、Oracle HTTP Server構成を正しくチューニングする必要があります。そうしないと、mod_plsqlの接続プーリングは有効に利用できなくなります。Oracle HTTP Serverリスナーは、プロセスの起動および停止を頻繁に行わないようにする必要があります。サイトの負荷を適切に分析して、Webサイトに対する平均の負荷を特定します。Oracle HTTP Server構成をチューニングして、httpdプロセスの数を、システムに対する平均の負荷を処理できるように設定する必要があります。さらに、httpd.confファイルの構成パラメータMaxClientsは、同様に、ランダムに発生する負荷の急激な上昇を処理できなければなりません。
UNIXシステムでは、Oracle HTTP Serverプロセスは、プロセスが最終的に停止して再起動されるように設定します。これは、Oracle HTTP Server経由でアクセスされる様々なコンポーネントで発生する可能性があるメモリー・リークを管理するために必要です。特に、mod_plsqlでは、データベース・セッションのリソース・リークが問題を引き起こさないようにするために必要となります。MaxRequestsPerChild構成パラメータが高い数値に設定されていることを確認してください。PL/SQLベースのWebアプリケーションの場合は、このパラメータを0（ゼロ）に設定しないでください。
負荷の高いサイトの場合、Oracle HTTP Serverの構成パラメータKeepAliveを無効にする必要があります。これにより、各プロセスは、現在のリクエストの処理が完了するとただちに他のクライアントからのリクエストを処理できるようになります。負荷が低く、Oracle HTTP Serverプロセスの数が常にOracle HTTP Serverリスナーに対する同時リクエストの数より多いサイトの場合、KeepAliveパラメータを有効にすると、パフォーマンスは向上します。このような場合、必ずKeepAliveTimeoutパラメータを適切にチューニングしてください。
Oracle HTTP Server構成でTimeoutの値を低くすることもできます。これにより、クライアントが適時にレスポンスを返さない場合、Oracle HTTP Serverプロセスはより早く解放されます。この値を低くしすぎないでください。値が低すぎると、その値より遅いクライアントのレスポンスがタイムアウトします。
ほとんどのWebサイトには、一貫したユーザー・インタフェースで各画面に表示される、静的イメージ・ファイルが多数あります。このようなファイルはほとんど変わることがないため、Oracle HTTP Serverリスナーにより処理される各イメージをmod_expiresでタグ付けすることで、システムに対する負荷を大幅に減らすことができます。また、Oracle Web CacheでWebサイトをフロントエンドにすることも検討してください。
Webサイトでのmod_expiresの使用が有効かどうかを確認する方法
Netscapeまたはページ・キャッシング情報を表示できる任意のブラウザを使用し、サイトで頻繁にアクセスされるWebページをいくつか開きます。各ページでマウスを右クリックし、ポップアップ・メニューから「ページ情報を表示」（または使用しているブラウザのこれに相当するコマンド）を選択します。ページ情報ウィンドウのトップ・パネルに、様々なイメージおよび静的コンテンツが多数表示される場合、そのサイトでのmod_expiresの使用は有効です。
また、Oracle HTTP Serverアクセス・ログをチェックして、HTTP 304（Not Modified）ステータスになるリクエストの割合を確認することもできます。grepユーティリティを使用してaccess_logの304を検索し、この結果の行数をaccess_logの合計の行数で割ります。この割合が高い場合、そのサイトでのmod_expiresの使用は有効です。
静的ファイルをExpiresヘッダーでタグ付けする方法
静的イメージ・ファイルの処理に使用されるLocationディレクティブを探します。ExpiresActiveおよびExpiresDefaultディレクティブを追加します。
Alias /images/ "/u01/app/oracle/myimages/"
<Directory "/u01/app/oracle/myimages/">
AllowOverride None
Order allow, deny
Allow from all
ExpiresActive On
ExpiresDefault A2592000
</Directory>
ブラウザは、現在から30日間、処理されるすべての静的ファイルを/imagesパスからキャッシュします。詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。
静的ファイルがExpiresヘッダーでタグ付けされているかどうかを確認する方法
Netscapeまたは任意のブラウザを使用して、ブラウザ内のすべてのキャッシュ済ファイルをクリーンアップします。
Expiresヘッダーでタグ付けされたイメージがあるWebページを開きます。ページでマウスを右クリックし、ポップアップ・メニューから「ページ情報を表示」を選択します。または、使用しているブラウザのこれに相当するコマンドを使用します。
ページ情報のトップ・パネルで、Expiresヘッダーでタグ付けされているイメージを選択します。
下部のパネルに表示される情報を確認します。Expiresヘッダーは有効な日付に設定されています。このエントリが「指定されていません」となっている場合、そのファイルはExpiresヘッダーでタグ付けされていません。
データベース・セッションの数をチューニングする際、次の項目について考慮してください。
Oracle init$SID.ora構成ファイルのprocessesおよびsessionsパラメータは、Oracleで最大数のデータベース・セッションを処理できるように設定する必要があります。この数は、DADの数にOracle HTTP Serverプロセスの最大数を掛け、さらにOracle HTTP Serverインスタンスの数を掛けた値に比例します。
2リスナー方針または共有サーバーを使用すると、データベース・セッションの数を減らすことができます。2リスナー方針に関する項を参照してください。
UNIXプラットフォームでは、接続プールはOracle HTTP Serverプロセス間で共有されません。このため、アプリケーションではできるだけ少ないDADを使用することをお薦めします。
Oracle HTTP Serverがプロセス・ベースであるプラットフォーム（すべてのUNIXベースのプラットフォームなど）では、サーブレット、PL/SQL、静的ファイルおよびCGIを含め、すべてのタイプのHTTPリクエストを各プロセスで処理します。1つのOracle HTTP Serverリスナー設定で、各httpdプロセスはデータベースへの独自の接続プールを保持します。データベース・セッションの最大数は、httpd.conf構成ファイルのStartServers、MinSpareServersおよびMaxSpareServersの設定およびシステムに対する負荷により決まります。このアーキテクチャでは、mod_plsqlリクエストの数に基づいてデータベース・セッションの数をチューニングできません。mod_plsqlリクエストの数に基づいてデータベース・セッションの数をチューニングするには、mod_plsqlリクエスト専用に別のHTTPリスナーをインストールします。この方法により、mod_plsqlリクエストの処理に必要なデータベース・セッションの数を大幅に減らすことができます。
たとえば、メインのOracle HTTP Serverリスナーがmylsnr1.mycompany.comのポート7777で稼働しているとします。まず、別のOracle HTTP Serverリスナーをmylsnr2.mycompany.comのポート8888にインストールします。次に、mylsnr1.mycompany.com:7777に対して行われたすべてのmod_plsqlリクエストを、mylsnr2.mycompany.com:8888の2番目のリスナーにリダイレクトします。手順は次のとおりです。
mylsnr1.mycompany.com:7777に対するすべてのPL/SQLリクエストをmylsnr2.mycompany.com:8888にリダイレクトするには、次のように構成を変更します。
ポート7777で稼働しているOracle HTTP Serverリスナーについては、ORACLE_HOME\ohs\conf\moduleconf\plsql.confファイルを編集します。行の先頭に#を挿入して、次の行をコメント化します。
#LoadModule plsql_module...
mylsnr1.mycompany.comのPL/SQLリクエストの処理に使用されるDADの場所を、mylsnr2.mycompany.comのINSTANCE_HOME\config\OHS\ohs1\mod_plsql\dads.conf構成ファイルにコピーします。
行の先頭に「#」を挿入して、mylsnr1.mycompany.com上のDADの場所の構成パラメータをコメント化します。
#<Location /pls/portal> #... #</Location>
次の行をdads.confに追加して、このDADの場所に対するすべてのmod_plsqlリクエストを2番目のリスナーに転送するように、このリスナーを設定します。
ProxyPass /pls/portal http://mylsnr2.mycompany.com:8888/pls/portal
すべてのDADの場所について、この設定の手順を繰り返します。
PL/SQLプロシージャはブラウザに表示されるURLを生成するため、すべてのURLがmylsnr2.mycompany.com:8888の内部mod_plsqlリスナーを参照せずに構成されていることが重要です。PL/SQLベースのWebアプリケーションでURLがどのように生成されるかにより、次の3つのオプションがあります。
URLがアプリケーションにハードコードされている場合、常にハードコードされた値（HOST=mylsnr1.mycompany.comおよびPORT=7777）を使用してURLが生成されていることを確認してください。この場合、変更は不要です。
PL/SQLベースのWebアプリケーションが常にCGI環境変数SERVER_NAMEおよびSERVER_PORTを使用する場合、mylsnr2.mycompany.comのリスナーの構成を変更することは簡単です。ファイルを編集し、2番目のリスナーのINSTANCE_HOME\config\OHS\ohs1\httpd.confファイルのServerNameおよびPort行を次のように変更します。
ServerName mylsnr1.mycompany.com (was mylsnr2.mycompany.com) Port 7777 (was 8888)
URLがCGI環境変数HTTP_HOSTを使用して生成されている場合、ポート8888で稼働しているOracle HTTP ServerリスナーのCGI環境変数をオーバーライドする必要があります。各DADのINSTANCE_HOME\config\OHS\ohs1\mod_plsql\dads.confファイルに次の行を追加して、デフォルトのCGI環境変数HOST、SERVER_NAMEおよびSERVER_PORTをオーバーライドします。
PlsqlCGIEnvironmentList SERVER_NAME mylsnr1.mycompany.com PlsqlCGIEnvironmentList SERVER_PORT 7777 PlsqlCGIEnvironmentList HOST mylsnr1.us.oracle.com:7777
いかなる場合でも、目的は、アプリケーションに2番目のリスナーが存在しないかのように見せかけて、URLを生成することです。
設定をテストし、すべてのDADに問題なくアクセスできることを確認します。
この設定では、mylsnr1.mycompany.comのメインのリスナーは、Oracle HTTP Serverリスナーに対する合計の負荷に基づいて設定できます。mylsnr2.mycompany.comの2番目のリスナーは、実行されるmod_plsqlリクエストのみに基づいて細かくチューニングできます。
一部のストアド・プロシージャの実行時、mod_plsqlにDescribeのオーバーヘッドが発生することがあり、その結果、実行を正常終了するために、データベースへのラウンドトリップが2回余分に発生します。これは、パフォーマンスと密接な関係があります。
PL/SQLプロシージャを実行するために、mod_plsqlは、渡されるパラメータのデータ型およびアクセスに必要な権限を認識する必要があります。この情報に基づいて、mod_plsqlは、各パラメータを配列またはスカラーとしてバインドします。プロシージャ・シグネチャを認識するための1つの方法は、プロシージャを実行前に記述することです。ただし、この方法は、各プロシージャを実行前に記述する必要があるため、効率的ではありません。Describeのオーバーヘッドを回避するには、mod_plsqlでパラメータ名ごとに渡されるパラメータの数を調べるようにします。この情報を使用して、各変数のデータ型を推定します。このロジックは単に、渡される値が1つの場合はそのパラメータをスカラーとし、それ以外の場合は配列とします。これは、ほとんどの場合において機能しますが、1つの値を配列パラメータに渡そうとしたり、複数の値をスカラーに渡そうとしている場合には機能しません。このような場合、プロシージャを実行する最初の試みに失敗します。mod_plsqlはDescribeコールを発行して、PL/SQLプロシージャのシグネチャを取得し、Describe操作で取得した情報に基づいて各パラメータをバインドします。プロシージャは再実行され、結果が戻されます。
このDescribeコールは、プロシージャに対して透過的に発生しますが、mod_plsqlの内部では、ラウンドトリップが2回余分に発生します。1回は実行に失敗したコールのためで、もう1回はDescribeコールのためです。
次のようにして、パフォーマンスの問題を回避できます。
柔軟なパラメータの受渡しを使用します。
配列に対して常に複数の値を渡すようにします。1つの値の場合、プロシージャで無視されるダミー値を渡すことができます。
回避策として、次のように、未使用の変数をデフォルトとする2パラメータ・スタイルのプロシージャを定義します。
元のプロシージャを内部的にコールする、プロシージャに相当するスカラーを定義します。たとえば、元のパッケージが次の例のようなものだとします。
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2(32767) INDEX BY binary_ integer; PROCEDURE arrayproc (arr myArrayType); END testpkg; /
/pls/.../testpkg.arrayproc? arr= 1のようなURLコールを作成している場合、仕様を次のように変更します。
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2( 32767) INDEX BY binary_integer; PROCEDURE arrayproc (arr varchar2); PROCEDURE arrayproc (arr myArrayType); END testpkg; /
プロシージャarrayprocは、次のようになります。
CREATE OR REPLACE PACKAGE BODY testpkg AS PROCEDURE arrayproc (arr varchar2) IS localArr myArrayType; BEGIN localArr( 1) := arr; arrayproc (localArr); END arrayproc;
ラウンドトリップのオーバーヘッドは、PL/SQLプロシージャが古いスタイルの4パラメータ・インタフェースを使用している場合に発生します。PL/SQL Gatewayは、最初に2パラメータ・インタフェースを使用してプロシージャの実行を試みます。これに失敗すると、PL/SQL Gatewayは4パラメータ・インタフェースを使用します。つまり、すべての4パラメータ・インタフェースのプロシージャでは、ラウンドトリップが1回余分に発生します。
柔軟なパラメータの受渡しのオーバーヘッドの回避
このオーバーヘッドを回避するには、対応するラッパーを作成して、2パラメータ・インタフェースを使用しながら内部的に4パラメータ・インタフェースのプロシージャをコールするようにすることをお薦めします。もう1つのオプションは、元のプロシージャの仕様を変更して、渡されないパラメータをデフォルトとして2パラメータ・インタフェースに設定することです。4パラメータ・インタフェースは、下位互換性のためにのみ提供されていますが、将来的には非推奨となります。
柔軟なパラメータと感嘆符の使用
Oracle HTTP Serverの柔軟なパラメータの受渡しモードでは、PL/SQLプロシージャのプロシージャ名の前に感嘆符が付いていると想定しています。Oracle HTTP Serverで使用されている自動検出方法はパフォーマンスと密接に関係するため、現在、Oracle HTTP Serverでの柔軟なパラメータの受渡しには感嘆符が必須です。Oracle HTTP Serverでは、各プロシージャは実行前に完全に記述されます。プロシージャDescribeコールにより、プロシージャのシグネチャが決まり、データベースへのラウンドトリップが必要となります。Oracle HTTP ServerのPL/SQL Gatewayでは、エンド・ユーザーがプロシージャの前に感嘆符を追加して、明示的に柔軟なパラメータの受渡し規則を指定することにより、このラウンドトリップを回避します。
ファイル・システム・キャッシュを構成して使用すると、Oracle Portalアプリケーションおよび一般的なPL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。
この項の内容は、次のとおりです。
この項では、mod_plsqlに関連するファイル・システム・キャッシュのチューニング・オプションについて説明します。キャッシュ・コンテンツは、オペレーティング・システム付属のファイル・システム・コールを使用してキャッシュされますが、キャッシュされたコンテンツはmod_plsqlのメモリー領域には格納されません。mod_plsqlのファイル・システム・キャッシュを使用していても、メモリー・ディスクなどの機能がオペレーティング・システムでサポートされ、それを使用するようにシステムが構成されている場合（一部のUNIXプラットフォームはメモリー・ディスク・ベースの高速格納をサポートしています）、キャッシュ・コンテンツはメモリーに存在することがあります。
この項の情報を使用すると、mod_plsqlがファイル・システム・キャッシュを使用するように構成されている場合に、PL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。たとえば、Oracle Portalではファイル・システム・キャッシュを使用しています。そのため、ファイル・システム・キャッシュが適切にチューニングされれば、Oracle Portalのパフォーマンスは向上します。
表4-3に、mod_plsqlに対して設定できるキャッシュ関連のパラメータを示します。これらのパラメータをcache.confファイルに設定します。このファイルは、UNIXではINSTANCE_HOME/config/OHS/ohs1/mod_plsql/dads.confディレクトリに、WindowsではINSTANCE_HOME\config\OHS\ohs1\mod_plsql\dads.confディレクトリにあります。
|
注意: confディレクトリのcache.READMEファイルには、各パラメータの詳細な説明や、パラメータ値の設定方法を示す例が含まれています。 |
表4-3 mod_plsql cache.confの構成パラメータの概要
| パラメータ | 説明 |
|---|---|
|
|
キャッシュ・クリーンアップ・ルーチンの実行間隔を設定します。 デフォルト: 関連項目: キャッシュ・クリーンアップの構成に関する項 |
|
|
mod_plsqlのキャッシュを保持するディレクトリを定義します。 デフォルト: UNIXシステムでは、エラー・ログのデフォルト・ディレクトリは${ORACLE_INSTANCE}/${COMPONENT_TYPE}/${COMPONENT_NAME}です。 Windowsシステムでは、エラー・ログのデフォルト・ディレクトリは${ORACLE_INSTANCE}\${COMPONENT_TYPE}\${COMPONENT_NAME}です。 関連項目: より高速なファイル・システムに存在するためのファイル・システム・キャッシュの構成に関する項 |
|
|
ファイル・システム・キャッシュを使用できるようにします。 デフォルト: 関連項目: ファイル・システム・キャッシュの有効化に関する項 |
|
|
キャッシュ・コンテンツのエージングを日単位で制御します。 デフォルト: 関連項目: PlsqlCacheMaxAgeによるキャッシュのエージング日数の設定に関する項 |
|
|
キャッシュに格納される個々のファイルの最大サイズをバイト単位で設定します。 デフォルト: 関連項目: PlsqlCacheMaxSizeによるキャッシュ・ファイルの最大ファイル・サイズの設定に関する項 |
|
|
キャッシュの合計サイズを制限します。この値はバイト単位で指定します。 デフォルト: 関連項目: PlsqlCacheTotalSizeによる合計キャッシュ・サイズの設定に関する項 |
cache.confのPlsqlCacheEnableパラメータにより、mod_plsqlキャッシングが使用できるようになります。パフォーマンスを最大化するには、PlsqlCacheEnableパラメータの値をOnに設定して有効にします。
|
注意: PL/SQLキャッシングをサポートするアプリケーション（Oracle Portalなど）でのみ、PlsqlCacheEnableをOnに設定するメリットがあります。 |
この項では、別のディスク上にあるようにファイル・システム・キャッシュを構成する方法について説明します。ファイル・システム・キャッシュを使用し、より高速な別のディスク上にキャッシュを格納すると、Oracle Portalや一般的なPL/SQLベースのWebアプリケーションなど、ファイル・システム・キャッシュを使用するすべてのタイプのWebアプリケーションについて、パフォーマンスは向上します。
ファイル・システム・キャッシュを構成する際、キャッシュを別の物理ディスクまたはメモリー・ディスクのいずれかに設定できます。
ファイル・システム・キャッシュを別のディスク上に設定するには、次のようにします。
キャッシュのファイル・システムは次の場所にあるとします。
UNIXの場合: /u01/cache
Windowsの場合: E:\cache
次のファイルを更新します。
UNIXの場合: INSTANCE_HOME/config/OHS/ohs1/mod_plsql/cache.conf
Windowsの場合: INSTANCE_HOME\config\OHS\ohs1\mod_plsql\cache.conf
キャッシュ・パラメータのPlsqlCacheDirectoryを次のように変更します。
UNIXの場合: PlsqlCacheDirectory /u01/cache
Windowsの場合: PlsqlCacheDirectory E:\cache
この項の内容は、次のとおりです。
デフォルトのインストールでは、mod_plsqlのファイル・システム・キャッシュ・サイズは2097152バイト（20MB）に設定されます。PL/SQLアプリケーションがOWA_CACHEパッケージを使用しない場合、またはパッケージを使用して少量のコンテンツをキャッシュする場合は、デフォルト設定で十分です。PL/SQLアプリケーションが大量のコンテンツをmod_plsqlのファイル・システム・キャッシュにキャッシュする場合、より高い値の指定を検討する必要があります。
キャッシュ・サイズを制御するには、cache.confファイルにPlsqlCacheTotalSizeパラメータを設定します。UNIXシステムでは、このファイルはINSTANCE_HOME/config/OHS/ohs1/mod_plsqlディレクトリにあります。Windowsシステムでは、このファイルはORACLE_HOME\config\OHS\ohs1\mod_plsqlにあります。
高いキャッシュ・ヒット率を達成するのに十分なキャッシュ・サイズを設定する必要があります。頻繁にアクセスされるコンテンツがキャッシュされた状態を維持するのに十分な大きさのキャッシュ・サイズを設定するようにしてください。また、キャッシュ・サイズが大きくなりすぎないように、ディスク領域の量を制限することも重要です。キャッシュ・サイズを適切にチューニングすると、頻繁にアクセスされるコンテンツすべてを保持するために十分なキャッシュを提供する一方で、非常に大きなキャッシュの検索は非効率であることから、キャッシュ・サイズが大きくなりすぎるのを防ぐこともできます。
PlsqlCacheTotalSizeの値はバイト数で指定します。1MBは1048576バイトです。この設定は、割り当てられるキャッシュ量に対する弱い制限です。場合によっては、次のクリーンアップ操作までに、キャッシュ・サイズがこの制限を超えて大きくなることがあります。そのため、キャッシュ・サイズに対する強い制限は、使用する物理ハード・ディスク・サイズとなります。この制限に達すると、領域が使用可能になるまで、キャッシュ・コンテンツをディスクに書き出すことができません。
|
注意: PlsqlCacheTotalSizeに使用できる最大値は、4294967296バイト（4GB）です。 |
適度なキャッシュ・サイズを決定するには、次のようにします。
httpd.confのLogLevelをinfoレベルに設定してmod_plsqlパフォーマンス・ロギングをオンにし、mod_plsqlロギングを使用できるようにします。
日次ベースでerror_logを監視します。UNIXシステムでは、エラー・ログのデフォルト・ディレクトリはORACLE_HOME/ohs/mod_plsql/logです。Windowsシステムでは、デフォルト・ディレクトリはORACLE_HOME\ohs\mod_plsql\logです。
mod_plsql error_logエントリは、次のような形式です。
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b time=128s limit=25600000b
意味は次のとおりです。
deletedは、クリーンアップ・プロセスで削除されたキャッシュ・ファイルの数です。
max_ageは、一定期間使用されていなかったために削除されたキャッシュ・ファイルの数および合計サイズです。
keptは、クリーンアップ・プロセス後に保持されたキャッシュ・ファイルの数および合計サイズです。
timeは、クリーンアップの実行にかかった時間です。
limitは、合計キャッシュ・サイズです。これは、PlsqlCacheTotalSize設定の値です。
エラー・ログのエントリは次のように解析します。
保持されたファイルの数と比較して多数のファイルが削除されている場合、これはキャッシュ・サイズが小さすぎることを明らかに示しています。おそらくキャッシュ・サイズを増やす必要があります。
保持されたファイルの数と比較して少数のファイルが削除されている場合、これはキャッシュ・サイズがおそらく大きすぎることを示しています。十分なディスク領域がある場合、そのままにしておくか、またはキャッシュ・サイズを減らしてディスク領域を解放できます。
PlsqlCacheMaxAgeパラメータを使用すると、キャッシュ・コンテンツの古さを制御できます。パラメータの値は日数単位で指定します。このパラメータのデフォルト値は30（日）です。これは、キャッシュ・コンテンツが30日以内であれば、キャッシュに保存されることを意味します。30日を過ぎると、コンテンツはクリーンアップ・プロセス時に削除対象とみなされます。
mod_plsql error_logのmax_age情報には、キャッシュ・ファイルのエージング情報が示されます。サイトが非常に動的なサイトである場合、この設定をより小さい値に構成します。通常、古いキャッシュ・コンテンツは再利用されないので、小さい値にしてもキャッシュ・ヒット率に影響を及ぼすことがないためです。サイトに多くの静的ページが含まれる場合、PlsqlCacheMaxAgeの値を増やし、クリーンアップ・プロセスでキャッシュ・コンテンツが故意に削除されないようにします。
PlsqlCacheMaxSizeパラメータを使用すると、キャッシュに格納される個々のファイルの最大サイズを指定できます。このパラメータを使用することで、1つのキャッシュ・ファイルでキャッシュ全体がいっぱいになる状態を回避できます。
このパラメータのデフォルト値は1048576（バイト）です。一般に、このパラメータは、合計キャッシュ・サイズの約1〜3%の値に設定します。
|
注意: PlsqlCacheMaxSizeに使用できる最大値は、4294967296バイト（4GB）です。 |
キャッシュ・クリーンアップ・パラメータにより、ファイル・システム・キャッシュを調査し、必要に応じてクリーンアップする頻度が決まります。キャッシュ・クリーンアップ・パラメータのPlsqlCacheCleanupTimeはcache.confファイルに指定されています。頻度は、毎日、毎週、毎月に設定できます。毎週のクリーンアップを指定する場合、曜日と時刻を指定できます。
mod_plsqlのPlsqlCacheCleanupTimeのデフォルト設定は、現地時間の毎日午後11時です。そのため、デフォルトでは、毎晩午後11時にクリーンアップ・ルーチンが実行されます。頻度を毎月に選択した場合、クリーンアップは毎月第1土曜日に行われます。
クリーンアップの頻度が高すぎるとキャッシュ・ヒット率が低くなり、クリーンアップの頻度が低すぎるとキャッシュのディスク使用量が過多になるため、このパラメータを適切に設定することが重要です。
クリーンアップ・アクティビティは、mod_plsql error_logのエントリを使用して監視します。エントリを分析して、クリーンアップ・パラメータのPlsqlCacheCleanupTimeをチューニングします。
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b time=128s limit=25600000b
次の事柄に注意してください。
クリーンアップ時間の値が大きい場合、クリーンアップの頻度の設定が低すぎることを示している可能性があります。クリーンアップ操作で、多数のキャッシュ・ファイルの調査または削除に時間がかかることをログが示している場合は、クリーンアップの頻度を高くすることで、クリーンアップ操作にかかる時間を減らすことができます。
クリーンアップ操作時に古さが理由で多数のファイルが削除されている場合、クリーンアップの頻度が低すぎることを示しています。この場合、頻度を高くして、クリーンアップで古いキャッシュ・コンテンツをより頻繁に削除できるようにします。
