미디어 파일용 VXML/CVP HTTP 캐시 이해

소개

이 문서에서는 미디어 파일의 VXML(Voice Extensible Markup Language)/CVP(Customer Voice Portal) HTTP(Hypertext Transfer Protocol) 캐시에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• VXML 게이트웨이
• CVP

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

HTTP Client Cache에서는 미디어 파일 저장과 관련된 두 가지 유형의 캐시가 있습니다.

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)을 나타냅니다.일반적으로 500,000개 이상의 고객 프롬프트(약 1분 길이)를 더 작고 관리하기 쉬운 조각으로 나누어야 로딩 및 캐싱을 원활하게 수행할 수 있습니다.예를 들어, 대기열 음악은 30초 프롬프트의 반복 루프일 수 있습니다. 또한 프롬프트를 스트리밍하기 때문에 전체 프롬프트를 재생하지 않으면 프롬프트가 캐시되지 않습니다.따라서 프롬프트를 관리 가능한 크기로 만드는 것이 좋습니다.

2단계. 게이트웨이와 HTTP 미디어 서버 간의 날짜/시간을 동기화합니다.

참고:동기화는 정확할 필요는 없지만 적어도 1분 또는 2분 내에 동기화해야 합니다.동기화되지 않은 시간은 프롬프트를 새로 고치지 않거나 모든 통화에서 새로 고침할 수 있습니다. 둘 다 바람직하지 않은 동작입니다.

3단계. 미디어 서버에서 콘텐츠 만료(예: 15분)를 설정합니다.

참고:IIS에서는 HTTP Header 탭에서 이 작업을 수행합니다.이 기간이 지나면 게이트웨이 프롬프트가 새로 고쳐집니다.선택한 기간은 프롬프트 재기록 빈도 및 수정 후 새 프롬프트 로드를 기다리는 시간을 반영해야 합니다.

4단계. 프로그램 > 관리 도구 > IIS 관리자로 이동합니다.

5단계. 수정할 .wav 파일로 이동합니다.

6단계. 그런 다음 > 속성 > HTTP 헤더를 마우스 오른쪽 버튼으로 클릭합니다.

7단계. 콘텐츠 만료 활성화

게이트웨이가 제대로 캐싱되는지 확인하는 방법

게이트웨이 캐싱을 올바르게 구성했는지 확인하려면 다음 단계를 수행하십시오.

클라이언트가 프롬프트를 요청할 때마다 미디어 서버의 IIS 로그가 기록됩니다.캐싱이 올바르게 설정된 경우 이러한 요청은 특정 프롬프트에 대해 약 X분마다 표시됩니다(X는 3단계에서 새로 고침 간격으로 정의됨).로그는 다음 위치에 있습니다.C:\WINNT\system32\LogFiles\W3SVC1\ex*

또는

게이트웨이에서 show http client cache를 실행합니다.Fresh Time 열은 HTTP 미디어 서버에 설정된 새로 고침 기간과 같아야 합니다.

예를 들어 새로 고침 기간이 15분으로 설정된 경우 이 값은 900초여야 합니다.Age 열은 프롬프트를 마지막으로 새로 고친 후 경과된 시간(초)을 표시합니다.일반적으로 이 숫자는 Fresh Time보다 적습니다.그러나 최근에 프롬프트에 액세스한 통화가 없는 경우 이 번호는 새 시간보다 클 수 있습니다.프롬프트는 통화에 의해 트리거되고 Fresh Time 프롬프트가 만료된 경우에만 새로 고쳐집니다.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 메시지 헤더 중 하나에 다음이 포함된 경우

                        

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

그러면 <value in seconds>가 이 파일의 FreshTime으로 사용됩니다.

2. (1)이 없지만 다음 두 헤더가 http 메시지에 포함된 경우

                       

Expires: <expiration date time>

Date: <Current date time>

그런 다음 <expiration date time> - <Current date time>을 이 파일의 FreshTime으로 사용합니다.

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. 마지막으로, 캐시 새로 고침 구성 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

최대 부실

클라이언트가 만료 시간을 초과한 응답을 수락할 의향이 있음을 나타냅니다.max-stale에 값이 할당되면 클라이언트는 지정된 시간(초)까지 만료 시간을 초과한 응답을 수락합니다.값이 max-stale에 할당되지 않은 경우 클라이언트는 어떤 연령의 오래된 응답을 기꺼이 수락합니다.

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

앞서 언급했듯이, 다음과 같은 경우 오래된 캐시된 항목은 소유자가 필요에 따라 제거합니다.

캐시된 항목이 오래됩니다.및

해당 ref 카운트는 0(0)입니다. 즉, 아무도 이 캐시된 항목을 사용하지 않습니다.및

다른 항목의 공간을 확보하기 위해 메모리 공간이 필요합니다.

즉, http 클라이언트 및 IVR Media Player는 각각 비스트리밍 및 스트리밍 모드에서 이러한 방식으로 캐시된 엔트리를 관리하고 제어해야 합니다.http 클라이언트가 일부 오래된 항목을 정리하여 캐시 메모리 풀의 공간을 재확보해야 하지만 해당 파일의 소유자가 아닌 경우 어떻게 합니까?  이는 http 클라이언트 캐시 백그라운드 관리자의 책임이 됩니다.

http 클라이언트 캐시 백그라운드 관리자는 5분마다 다시 일어납니다.캐시된 항목에 사용된 총 메모리가 구성된 캐시 메모리 풀 크기의 임계값 70%를 초과하면 관리자는 캐시된 모든 항목을 단계별로 살펴봅니다.여전히 새 항목이 있으면 그대로 둡니다.항목이 오래되어 참조에 대한 참조가 없는 경우(예: ref count = 0), http 클라이언트는 해당 항목의 올바른 소유자이므로 해당 항목을 자체적으로 삭제합니다.부실 항목에 참조 카운트 1이 있고 연결된 상위 또는 하위 항목이 없는 경우, 파일이 새로 고침 다운로드 중에 있지 않음을 의미합니다. http 클라이언트가 다시 호출하여 이 오래된 항목을 릴리스하도록 Media Player에 알립니다.

오디오 프롬프트 로드 명령

경우에 따라 오디오 파일을 라우터에 수동으로 다운로드하는 것이 좋거나 필요할 수 있습니다.지금까지 라우터가 오래된 캐시된 항목을 새로 고치도록 http 서버로 자동으로 이동하지 않는다는 메시지가 이미 있습니다.이러한 항목은 필요한 경우에만 새로 고쳐집니다.  수동 다운로드로 이 문제를 해결할 수 있습니다.

수동 다운로드가 유용할 수 있는 또 다른 시나리오는 비스트리밍 모드에서 큰 오디오 프롬프트를 미리 로드하는 것입니다.이 작업은 발신자가 프롬프트 로드 지연을 경험하지 않도록 첫 번째 통화를 수신하기 전에 수행할 수 있습니다.

특정 오디오 파일을 수동으로 다운로드하려면 다음 CLI 명령을 실행합니다.

오디오 프롬프트 로드 <url>

<url>은 서버에 있는 오디오 파일입니다.물론 이 파일을 캐시에 저장하도록 http 클라이언트 캐시가 올바르게 구성되어야 합니다. 

참고:<url>이 활성 프롬프트인 경우(즉, 현재 재생 중인 경우 이 CLI는 적용되지 않습니다.

날짜 시간

또한 게이트웨이와 HTTP 미디어 서버 간의 날짜/시간이 동기화되었는지 확인합니다.이것은 필수 사항입니다.

경고:VXML GW에서 clear http 클라이언트 캐시를 사용하지 마십시오.이 명령이 로드되고 활성화된 VXML GW에서 호출되면 문제, 메모리 손상 및 충돌을 일으키는 것으로 알려져 있습니다.기본적으로 clear ip http 클라이언트 캐시를 모두 사용하지 않는 것이 좋습니다.이 작업은 캐시의 모든 항목을 새로 고침하며, 캐시 링크 목록에서 노드를 만들고 삭제하여 몇 가지 문제를 발생시킵니다.Cisco IOS®에서 명령을 제거하는 중입니다.권장 명령은 http 클라이언트 캐시 부실으로 설정되며, 이 명령은 새로 변경된 캐시 부분을 새로 고치는 것입니다.