VXML-/CVP-HTTP-Cache für Mediendateien verstehen

Einführung

Dieses Dokument beschreibt den VXML- (Voice Extensible Markup Language)/CVP-Hypertext Transfer Protocol- (HTTP)-Cache (Customer Voice Portal) für Mediendateien.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• VXML-Gateway
• CVP

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Im HTTP-Client-Cache gibt es zwei Cachetypen, die zum Speichern von Mediendateien erforderlich sind:

1. Der IVR Media Player-Cache und
2. Der HTTP-Client-Cache

Die Servercache-Einstellung überschreibt die HTTP-Clienteinstellungen, diese Parameter werden vom Server entweder über HTTP-Nachrichtenheader oder über VXML-Anwendungsskripts gesendet.

Überlegungen zum Zwischenspeichern von Gateway-Eingabeaufforderungen

Schritt 1: Wenn Audioansagen auf einem HTTP-Medienserver gespeichert werden, sind geeignete Caching-Methoden für Gateway-Aufforderungen erforderlich, um sowohl die Leistung des Gateways als auch die Bandbreitennutzung im Netzwerk zu optimieren. Die Gateway-Leistung nimmt um etwa 35-40 % ab, wenn die Zwischenspeicherung vollständig deaktiviert ist.

Um die Zwischenspeicherung auf dem Gateway zu konfigurieren, legen Sie diese auf dem Gateway fest:

..ivr prompt memory 15000

..http client cache memory file 500

..http client cache memory pool 15000

Hinweis: Die HTTP-Client-Cache-Speicherdatei stellt die größte Aufforderungsdatei (in Kbyte) dar, die zwischengespeichert werden kann. Im Allgemeinen müssen Kundenaufforderungen mit einer Länge von mehr als 500 K (etwa eine Minute) in kleinere, besser verwaltbare Teile aufgeteilt werden, um das Laden und Zwischenspeichern zu vereinfachen. Warteschlangenmusik kann beispielsweise eine sich wiederholende Schleife einer 30-Sekunden-Eingabeaufforderung sein. Beachten Sie auch, dass die Eingabeaufforderung nur zwischengespeichert wird, wenn die gesamte Eingabeaufforderung abgespielt wird, da die Aufforderungen gestreamt werden. Es wird daher empfohlen, Aufforderungen in einer überschaubaren Größe auszufüllen.

Schritt 2: Synchronisieren Sie die Datenzeit zwischen dem Gateway und dem HTTP-Medienserver.

Hinweis: Die Synchronisierung muss nicht exakt sein, sondern mindestens innerhalb von ein oder zwei Minuten. Nicht synchronisierte Zeiten können dazu führen, dass Aufforderungen nie aktualisiert werden, oder dass sie bei jedem Anruf aktualisiert werden. Beide Aufforderungen sind unerwünschte Verhaltensweisen.

Schritt 3: Legen Sie auf dem Medienserver den Ablauf des Inhalts fest (z. B. 15 Minuten).

Hinweis: In IIS erfolgt dies über die Registerkarte HTTP Header. Die Gateway-Eingabeaufforderung wird nach diesem Zeitraum aktualisiert. Der gewählte Zeitraum muss die Häufigkeit der erneuten Aufnahmen von Aufforderungen und die Wartezeit beim Laden der neuen Eingabeaufforderung nach der Änderung widerspiegeln.

Schritt 4: Navigieren Sie zu Programme > Verwaltung > IIS-Manager.

Schritt 5: Navigieren Sie zur Datei .wav, die Sie ändern möchten.

Schritt 6: Klicken Sie dann mit der rechten Maustaste auf > Eigenschaften > HTTP-Header.

Schritt 7: Aktivieren Sie Content Expiration.

Ermitteln, ob das Gateway korrekt zwischenspeichert

Um festzustellen, ob das Gateway-Caching ordnungsgemäß konfiguriert wurde, gehen Sie folgendermaßen vor:

Das IIS-Protokoll auf dem Medienserver zeichnet jedes Mal auf, wenn ein Client eine Eingabeaufforderung anfordert. Wenn die Zwischenspeicherung korrekt eingerichtet ist, werden diese Anfragen für eine bestimmte Eingabeaufforderung etwa alle X Minuten (X ist das, was in Schritt 3 als Aktualisierungsintervall definiert wurde) angezeigt. Das Protokoll finden Sie unter: C:\WINNT\system32\LogFiles\W3SVC1\ex*

Oder:

Führen Sie show http client cache auf dem Gateway aus. Die Spalte "Fresh Time" muss der Aktualisierungszeit entsprechen, die auf dem HTTP-Medienserver festgelegt wurde.

Wenn der Aktualisierungszeitraum beispielsweise auf 15 Minuten festgelegt wurde, muss dies 900 Sekunden dauern. Die Spalte Alter zeigt an, wie viele Sekunden vergangen sind, seit die Eingabeaufforderung zuletzt aktualisiert wurde. Im Allgemeinen ist diese Zahl kleiner als die Fresh Time. Wenn jedoch in letzter Zeit noch kein Anruf auf die Eingabeaufforderung zugegriffen hat, kann diese Nummer größer sein als die aktuelle Uhrzeit. Aufforderungen werden nur aktualisiert, wenn sie durch einen Anruf ausgelöst werden und die Aufforderung Fresh Time abgelaufen ist. Wenn die Fresh Time ein sehr hoher Wert ist, können Sie die Eingabeaufforderung nur aus dem Cache entfernen (mit Ausnahme der ausgeblendeten Befehle), indem Sie das Gateway neu laden.

Es ist viel einfacher, den Header einfach als echten HTTP-Header über IIS hinzuzufügen.

Dies kann über IIS 6 oder 7 erfolgen.

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

FreshTime berechnen

Es gibt mehrere Variablen, die die FreshTime einer Datei beeinflussen können, z. B.: HTTP-Nachrichtenheader vom Server und Cache-Aktualisierungswert, konfiguriert über die CLI usw.

Woher wissen Sie also, welchen Wert eine Datei für ihre FreshTime verwendet? Die FreshTime einer Datei wird in der folgenden Rangfolge bestimmt:

1. Wenn eine Datei vom HTTP-Server heruntergeladen wird, wenn einer der HTTP-Nachrichtenheader Folgendes enthält:

                        

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

Anschließend wird der <Wert in Sekunden> als FreshTime für diese Datei verwendet.

2. Wenn (1) nicht vorhanden ist, aber diese beiden Header in der http-Nachricht enthalten sind:

                       

Expires: <expiration date time>

Date: <Current date time>

Anschließend wird die Differenz <Ablaufdatum> - <Aktuelles Datum Uhrzeit> als FreshTime für diese Datei verwendet.

3. Die HTTP/1.1-Spezifikation RFC 2616 (HTTP) empfiehlt, dass einer der unter (1) oder (2) beschriebenen HTTP-Nachrichtenheader vorhanden ist.  Wenn der Server in seiner HTTP-Antwort nicht sowohl (1) als auch (2) sendet, können Sie 10 % des Unterschieds zwischen Datum und Letzte Änderung aus den Nachrichtenheadern übernehmen:

                     

Last-Modified: <last-modified date time>

Date: <Current date time>

Die FreshTime für diese Datei wird wie folgt berechnet:

       

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

4. Schließlich kommt die CLI für die Cache-Aktualisierung ins Spiel. Mit der CLI kann der Benutzer den Dateien einen heuristischen FreshTime-Wert als vorläufigen Wert zuweisen, wenn keine der oben (1)-(3) Nachrichtenheader vorhanden ist.

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

Der Standardwert für die Aktualisierung ist 86.400 Sekunden (24 Stunden).

Hinweis: Die konfigurierte Aktualisierung des HTTP-Client-Cache hat keine Auswirkungen auf Dateien, wenn eine der Nachrichtenheader (1) - (3) vorhanden ist.

Hinweis: Diese CLI ist, sofern sie tatsächlich vorhanden ist, nicht rückwirkend. Das heißt, der neu konfigurierte Aktualisierungswert gilt nur für neue eingehende Dateien. Sie hat keine Auswirkungen auf die bereits im Cache vorhandenen Einträge.

Entfernen von veralteten zwischengespeicherten Einträgen

Hinweis: Der Router aktualisiert keine veralteten Dateien automatisch.

Veraltete Dateien werden nur bei Bedarf aktualisiert. Warum sollte der Router seine wertvollen CPU-Zyklen für die Aktualisierung der Dateien im Cache ausgeben, ohne zu wissen, ob oder wann diese Dateien verwendet werden sollen, während die CPU für andere dringende Dienste benötigt wird?

Dies bedeutet, dass ein veralteter zwischengespeicherter Eintrag lange im Cache verbleiben kann, bis er entfernt wird, um Platz für eine neue Kopie derselben Datei oder für eine andere Datei zu schaffen, die nur ihren Speicherplatz im Cache benötigt. Manchmal kann ein veralteter zwischengespeicherter Eintrag noch verwendbar sein, wenn sein Alter den MaxStale-Wert, der von der Anwendung angegeben wird, nicht überschreitet.

Kurz gesagt, ob ein zwischengespeicherter Eintrag veraltet oder noch verwendbar ist, kann mit den folgenden einfachen Vergleichen berechnet werden:

-        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

Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, die die Ablaufzeit überschritten hat. Wenn max-stale ein Wert zugewiesen wird, akzeptiert der Client eine Antwort, die die Ablaufzeit um nicht mehr als die angegebene Anzahl von Sekunden überschritten hat. Wenn max-stale keine Werte zugewiesen werden, ist der Client bereit, eine veraltete Antwort eines jeden Alters zu akzeptieren.

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

Wie bereits erwähnt, wird ein veralteter zwischengespeicherter Eintrag vom Eigentümer nach Bedarf entfernt, wenn:

Der zwischengespeicherte Eintrag ist veraltet. und

Die ref-Anzahl ist 0 (0), d. h., dieser zwischengespeicherte Eintrag wird von niemandem verwendet. und

Sein Arbeitsspeicher wird benötigt, um Platz für andere Einträge zu schaffen

Dies bedeutet, dass der HTTP-Client und der IVR Media Player ihre zwischengespeicherten Einträge in einem nicht-Streaming- bzw. Streaming-Modus verwalten und steuern müssen. Was ist, wenn der http-Client einige veraltete Einträge bereinigen muss, um Speicherplatz im Cache-Speicherpool zurückzugewinnen, aber nicht der Besitzer dieser Dateien ist? Dies ist Aufgabe des HTTP-Client-Cache-Hintergrundagers.

Der Hintergrundager des HTTP-Client-Cache wird alle 5 Minuten gestartet. Wenn der für die zwischengespeicherten Einträge verwendete Gesamtspeicher den Grenzwert von 70 % der konfigurierten Cache-Speicherpool-Größe überschreitet, durchläuft der Manager jeden zwischengespeicherten Eintrag. Wenn der Eintrag noch frisch ist, bleibt er in Ruhe. Wenn der Eintrag veraltet ist und keinen Verweis auf ihn enthält, d. h., ref count = 0 (ref count = 0), löscht der http-Client den Eintrag aus eigener Kraft, da er der legitime Besitzer des Eintrags ist. Wenn der veraltete Eintrag eine Verweiszählung 1 hat und kein übergeordnetes oder untergeordnetes Element mit ihm verknüpft ist, d. h. die Datei befindet sich nicht mitten im Aktualisierungsdownload, ruft der http-Client zurück, um den Media Player zu benachrichtigen, um diesen veralteten Eintrag freizugeben.

Audio Prompt Load-Befehl

Manchmal kann es wünschenswert oder notwendig sein, eine Audiodatei manuell auf den Router herunterzuladen. Inzwischen wird uns bereits mitgeteilt, dass der Router nicht automatisch zum HTTP-Server wechselt, um veraltete zwischengespeicherte Einträge zu aktualisieren. Diese Einträge werden nur aktualisiert, wenn sie benötigt werden.  Durch einen manuellen Download kann dieses Problem behoben werden.

Ein weiteres Szenario, das ein manueller Download nützlich sein kann, ist das Vorladen einer großen Audioaufforderung im Nicht-Streaming-Modus. Dies kann vor dem Empfang des ersten Anrufs erfolgen, sodass der Anrufer keine Verzögerung beim Aufrufen der Aufforderung erfährt.

Führen Sie den folgenden CLI-Befehl aus, um eine bestimmte Audiodatei manuell herunterzuladen:

Audio-Prompt-Laden <url>

Im <url> befindet sich die Audiodatei auf dem Server. Natürlich wird erwartet, dass der HTTP-Client-Cache korrekt konfiguriert ist, um diese Datei im Cache zu speichern. 

Hinweis: Wenn es sich bei der <url> um eine aktive Eingabeaufforderung handelt, d. h. die derzeit abgespielt wird, wird diese CLI nicht wirksam.

Datum Uhrzeit

Stellen Sie außerdem sicher, dass die Datenzeit zwischen dem Gateway und dem HTTP-Medienserver synchronisiert ist. Das ist ein Muss.

Warnung: Verwenden Sie keinen eindeutigen HTTP-Client-Cache im VXML-GW. Wenn dieser Befehl auf einem sehr geladenen/aktiven VXML-GW aufgerufen wird, kann er Probleme, Speicherbeschädigungen und Abstürze verursachen. Grundsätzlich wird die Verwendung von clear ip http client cache alles nicht empfohlen. Dabei werden alle Einträge aus dem Cache aktualisiert, und es werden Knoten aus der Liste der verknüpften Cache erstellt und gelöscht, was einige Probleme verursacht. Der Befehl wird gerade aus Cisco IOS® entfernt. Der empfohlene Befehl ist festgelegt, dass der HTTP-Client-Cache veraltet ist. Dieser Befehl aktualisiert lediglich den neu geänderten Teil des Cache.