メディアファイルのVXML/CVP HTTPキャッシュについて

概要

このドキュメントでは、メディアファイル用のVoice Extensible Markup Language(VXML)/Customer Voice Portal(CVP)Hypertext Transfer Protocol(HTTP)キャッシュについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• VXML ゲートウェイ
• CVP

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

HTTPクライアントキャッシュには、メディアファイルの保存に関連する2種類のキャッシュがあります。

1. IVR Media Playerキャッシュと
2. HTTPクライアントキャッシュ

サーバキャッシュ設定はHTTPクライアント設定を上書きし、これらのパラメータはhttpメッセージヘッダーまたはvxmlアプリケーションスクリプトを介してサーバから送信されます。

ゲートウェイプロンプトキャッシングの考慮事項

ステップ1：音声プロンプトがHTTPメディアサーバに保存される場合、ゲートウェイのパフォーマンスとネットワーク帯域幅使用量の両方を最適化するために、適切なゲートウェイプロンプトキャッシング方式が必要です。キャッシュを完全に無効にすると、ゲートウェイのパフォーマンスが約35 ～ 40 %低下します。

ゲートウェイでキャッシングを設定するには、ゲートウェイで次のように設定します。

..ivr prompt memory 15000

..http client cache memory file 500

..http client cache memory pool 15000

注：httpクライアントのキャッシュメモリファイルは、キャッシュ可能な最大サイズのプロンプトファイル（KB単位）を表します。一般的に、ロードとキャッシングを容易にするために、500K（約1分間）を超える顧客のプロンプトを、より小さく、より管理しやすい部分に分割する必要があります。たとえば、キュー音楽は30秒のプロンプトの繰り返しループになる可能性があります。また、プロンプトがストリームされるため、プロンプト全体が再生されない限り、プロンプトはキャッシュされません。したがって、プロンプトを管理可能なサイズにすることをお勧めします。

ステップ2：ゲートウェイとHTTPメディアサーバの間で日時を同期します。

注：同期は正確である必要はありませんが、少なくとも1 ～ 2分以内に行ってください。同期されていない時間は、プロンプトが更新されないことや、すべてのコール（両方とも望ましくない動作）で更新されることがあります。

ステップ3：メディアサーバで、コンテンツの有効期限を設定します（例：15分）。

注：IISでは、[HTTP Header]タブで行います。ゲートウェイのプロンプトは、この期間が経過すると更新されます。選択する期間は、プロンプトを再録音する頻度と、変更後に新しいプロンプトがロードされるのを待つ時間を反映する必要があります。

ステップ4:[Programs] > [Administrative Tools] > [IIS Manager]に移動します。

ステップ5：変更する.wavファイルに移動します。

ステップ6：次に、右クリック> [Properties] > [HTTP Headers]

ステップ7：コンテンツの有効期限を有効にします。

ゲートウェイが正しくキャッシュされているかどうかを確認する方法

ゲートウェイキャッシングが正しく設定されているかどうかを確認するには、次の手順を実行します。

メディアサーバのIISログは、クライアントがプロンプトを要求するたびに記録されます。キャッシュが正しく設定されている場合、これらの要求は特定のプロンプトに対してX分（Xはステップ3で更新間隔として定義されたものです）ごとに表示されます。ログは次の場所にあります。C:\WINNT\system32\LogFiles\W3SVC1\ex*

または、

ゲートウェイでshow http client cacheを実行します。[フレッシュタイム]列は、HTTPメディアサーバーに設定されている更新期間と等しくなければなりません。

たとえば、更新期間が15分に設定されている場合、900秒と表示されます。[Age]列には、プロンプトが最後に更新されてから経過した秒数が表示されます。一般に、この数字はフレッシュタイムより少ない。ただし、最近プロンプトにアクセスしたコールがない場合は、この番号が新しい時刻より大きくなる可能性があります。プロンプトが更新されるのは、コールによってトリガーされ、プロンプトのフレッシュタイムが期限切れになった場合だけです。Fresh Timeが非常に高い値である場合は、隠しコマンド以外のプロンプトをキャッシュから削除する唯一の方法は、ゲートウェイをリロードすることです。

IISを介してヘッダーを実際のHTTPヘッダーとして追加するだけで、はるかに簡単です。

これは、IIS 6または7を使用して実行できます。

http://weblogs.asp.net/joelvarty/archive/2009/03/23/force-ie7-compatibility-mode-in-ie8-with-iis-settings.aspx

FreshTimeの計算

ファイルのFreshTimeに影響を与える可能性のある変数には、次のようなものがあります。サーバからのhttpメッセージヘッダー、およびCLIなどで設定されたキャッシュ更新値。

では、ファイルがFreshTimeにどの値を使用しているのかを知るにはどうすればよいでしょうか。ファイルのFreshTimeは、次の優先順位で決定されます。

1. httpサーバからファイルをダウンロードするときに、httpメッセージヘッダーの1つに次の情報が含まれている場合：

                        

Cache-Control: max-age = <value in seconds>

その後、<value in seconds>がこのファイルのFreshTimeとして使用されます。

2. (1)が存在しない場合、次の2つのヘッダーがhttpメッセージに含まれます。

                       

Expires: <expiration date time>

Date: <Current date time>

次に、このファイルのFreshTimeとして<expiration date time> - <Current date time>の差分が使用されます。

3. HTTP/1.1仕様のRFC 2616 (HTTP)では、(1)または(2)に記載されているhttpメッセージヘッダーのいずれかを使用することを推奨しています。  サーバがhttp応答で(1)と(2)の両方を送信できなかった場合、メッセージヘッダーからDateとLast-Modifiedの差の10%を取得できます。

                     

Last-Modified: <last-modified date time>

Date: <Current date time>

したがって、このファイルのFreshTimeは次のように計算されます。

       

FreshTime = 10% x ((Last-Modified) - (Date))

4.最後に、これはcache refresh config CLIが起動したときです。CLIでは、上記(1)-(3)のメッセージヘッダが存在しない場合に、ユーザはヒューリスティックなFreshTime値を暫定値としてファイルに割り当てることができる。

c5400-02(config)#http client cache refresh ?
  <1-864000>           Time value in seconds

デフォルトの更新値は86400秒（24時間）です。

注：設定されたhttpクライアントキャッシュの更新は、メッセージヘッダー(1)～(3)が存在する場合は、ファイルに影響しません。

注：このCLIは、実際には遡及的ではありません。つまり、新しく設定された更新値は、新しい着信ファイルにのみ適用されます。すでにキャッシュ内にあるエントリには影響しません。

古いキャッシュエントリの削除

注：ルータは自動的に古いファイルを更新しません。

古いファイルは、必要に応じてのみ更新されます。他の緊急サービスにCPUが必要な場合に、ルータがキャッシュ内のファイルを使用するかどうか、またはいつ使用されるのかを知らずに、貴重なCPUサイクルを使用してファイルを更新するのはなぜですか。

つまり、古いキャッシュされたエントリは、同じファイルの新しいコピーを作成するために削除されるか、キャッシュ内のメモリ領域を必要とする別のファイルのために削除されるまで、長い間キャッシュ内に留まります。古いキャッシュされたエントリが、アプリケーションによって指定されたMaxStale値を超えていない場合にも、使用可能になることがあります。

要約すると、キャッシュされたエントリが古いか、まだ使用可能かにかかわらず、次の簡単な比較で計算できます。

-        file is fresh                                    if FreshTime > Age

 

-        file is stale but still usable         if (FreshTime + MaxStale) > Age

 

-        file is stale and not usable         if (FreshTime + MaxStale) <= Age

MaxStale

有効期限を超えた応答をクライアントが受け入れることを示します。max-staleに値が割り当てられている場合、クライアントは、指定された秒数を超えない有効期限を超えた応答を受け入れます。max-staleに値が割り当てられていない場合、クライアントは任意の経過時間の古い応答を受け入れます。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

前述したように、古いキャッシュエントリは、次の場合に必要に応じて所有者によって削除されます。

キャッシュされたエントリが古くなり、と

この参照カウントはゼロ(0)です。つまり、このキャッシュエントリを使用しているユーザはいません。と

他のエントリ用のスペースを確保するには、メモリ領域が必要です

これは、httpクライアントとIVR Media Playerが、それぞれ非ストリーミングモードとストリーミングモードで、キャッシュされたエントリを管理および制御する必要があることを意味します。HTTPクライアントがキャッシュメモリプールの領域を回復するために古いエントリをクリーンアップする必要があるが、そのファイルの所有者ではない場合はどうすればいいですか。  これは、http client cache background agerの責任になります。

http client cache background agerは5分ごとに起動します。キャッシュエントリに使用される合計メモリが、設定されているキャッシュメモリプールサイズの70 %のしきい値を超えると、Agerはすべてのキャッシュエントリをウォークします。まだ新しいエントリの場合は、そのままにしておきます。エントリが古く、そのエントリへの参照がない場合(ref count = 0)は、httpクライアントがそのエントリの正当な所有者であるため、自身でエントリを削除します。古いエントリに参照カウント1が含まれ、そのエントリにリンクされている親または子がない場合（ファイルが更新ダウンロードの途中にないことを意味する）、httpクライアントはMedia Playerに呼び戻し、古いエントリを解放します。

オーディオプロンプトロードコマンド

場合によっては、オーディオファイルを手動でルータにダウンロードすることが望ましいことや必要になることがあります。この時点ですでに、ルータが自動的にhttpサーバに移動して、古いキャッシュエントリを更新しないことを示しています。これらのエントリは、必要なときにのみ更新されます。  手動ダウンロードによってこの問題を解決できます。

手動ダウンロードが便利なもう1つのシナリオは、非ストリーミングモードで大きな音声プロンプトをプリロードすることです。これは、最初のコールを受信する前に実行できるため、発信者にプロンプトのロードの遅延が発生しません。

特定のオーディオファイルを手動でダウンロードするには、次のCLIコマンドを実行します。

audio-prompt load <url>

<url>は、サーバ上のオーディオファイルの場所です。もちろん、httpクライアントキャッシュは、このファイルをキャッシュに保存するように適切に設定されている必要があります。 

注：<url>がアクティブなプロンプトである場合（つまり、現在再生中）、このCLIは有効になりません。

日時

また、ゲートウェイとHTTPメディアサーバ間の日時が同期されていることを確認します。これは必然だ。

警告：VXML GWではclear http client cacheを使用しないでください。このコマンドが非常に負荷が高い/アクティブなVXML GWで呼び出された場合、問題の原因は、メモリの破損とクラッシュであることがわかります。基本的に、clear ip http client cache allの使用は推奨されません。キャッシュのすべてのエントリを更新し、キャッシュのリンクリストからノードを作成して削除すると、問題が発生します。このコマンドはCisco IOS®から削除される途中です。推奨されるコマンドはset http client cache staleです。このコマンドは、キャッシュの新しく変更された部分を更新するだけです。