Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit le cache HTTP (Hypertext Transfer Protocol) VXML (Voice Extensible Markup Language) / CVP (Customer Voice Portal) pour les fichiers multimédias.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Dans le cache client HTTP, deux types de cache sont impliqués dans le stockage des fichiers multimédias :
Le paramètre de cache du serveur remplace les paramètres du client HTTP. Ces paramètres sont envoyés à partir du serveur via des en-têtes de message http ou via des scripts d'application vxml.
Étape 1. Lorsque des invites audio sont stockées sur un serveur multimédia HTTP, des méthodes de mise en cache d'invite de passerelle appropriées sont nécessaires afin d'optimiser les performances de la passerelle et la consommation de bande passante du réseau. Les performances de la passerelle diminuent d'environ 35 à 40 % si la mise en cache est entièrement désactivée.
Afin de configurer la mise en cache sur la passerelle, définissez ces paramètres sur la passerelle :
..ivr prompt memory 15000 ..http client cache memory file 500 ..http client cache memory pool 15000
Note: Le fichier de mémoire cache du client http représente le fichier d'invite de la plus grande taille (en Ko) qui peut être mis en cache. En général, les invites du client de plus de 500 000 (environ une minute de longueur) doivent être divisées en pièces plus petites et plus faciles à gérer afin de faciliter le chargement et la mise en cache. Par exemple, la musique d'attente peut être une boucle répétitive d'une invite de 30 secondes. Notez également que comme les invites sont diffusées en continu, l'invite ne cache pas, sauf si l'invite entière est lue. Par conséquent, il est recommandé de faire des invites une taille gérable.
Étape 2. Synchronisez la date et l'heure entre la passerelle et le serveur multimédia HTTP.
Note: La synchronisation n'a pas besoin d'être exacte, mais au moins dans une minute ou deux. Les heures qui ne sont pas synchronisées peuvent empêcher l'actualisation des invites ou les actualiser avec chaque appel, deux comportements indésirables.
Étape 3. Sur le serveur multimédia, définissez l'expiration du contenu (par exemple, 15 minutes).
Note: Dans IIS, cela se fait sous l'onglet En-tête HTTP. L'invite de la passerelle est actualisée après cette période. La période choisie doit refléter la fréquence d'enregistrement des invites et la durée pendant laquelle vous êtes prêt à attendre que la nouvelle invite soit chargée après modification.
Étape 4. Accédez à Programmes > Outils d'administration > Gestionnaire IIS.
Étape 5. Accédez au fichier .wav à modifier.
Étape 6. Ensuite, cliquez avec le bouton droit de la souris > Propriétés > En-têtes HTTP
Étape 7. Activez l'expiration du contenu.
Afin de déterminer si vous avez correctement configuré la mise en cache de la passerelle, procédez comme suit :
Le journal IIS sur le serveur multimédia enregistre chaque fois qu'un client demande une invite. Si la mise en cache est configurée correctement, ces requêtes apparaissent environ toutes les X minutes (X correspond à l'intervalle d'actualisation défini à l'étape 3.) pour une invite particulière. Le journal se trouve à l'adresse suivante : C:\WINNT\system32\LogFiles\W3SVC1\ex*
OU,
Exécutez show http client cache sur la passerelle. La colonne Fresh Time doit être égale à la période de rafraîchissement définie sur le serveur multimédia HTTP.
Par exemple, si la période d'actualisation a été définie sur 15 minutes, cela doit indiquer 900 secondes. La colonne Age indique le nombre de secondes écoulées depuis la dernière actualisation de l'invite. En général, ce nombre est inférieur au temps nouveau. Toutefois, si aucun appel n'a été consulté récemment, ce numéro peut être supérieur à l'heure actuelle. Les invites ne sont actualisées que lorsqu'elles sont déclenchées par un appel et que l'invite Fresh Time a expiré. Si la valeur Fresh Time est très élevée, la seule façon de supprimer l'invite du cache (autre que les commandes masquées) est de recharger la passerelle.
Il est beaucoup plus facile d'ajouter l'en-tête en tant qu'en-tête HTTP réel via IIS.
Cela peut être fait via IIS 6 ou 7.
Il existe plusieurs variables qui peuvent affecter FreshTime d'un fichier, telles que : En-têtes de message http à partir du serveur et valeur d'actualisation du cache configurée via l'interface de ligne de commande, etc.
Comment savez-vous quelle valeur un fichier utilise pour son FreshTime ? La Fraîcheur d'un fichier est déterminée dans cette priorité :
1. Lorsqu'un fichier est téléchargé à partir du serveur http, si l'un des en-têtes de message http contient ceci :
Cache-Control: max-age = <value in seconds>
Ensuite, la <valeur en secondes> est utilisée comme FreshTime pour ce fichier.
2. Si (1) n'est pas présent, mais que ces deux en-têtes sont inclus dans le message http :
Expires: <expiration date time> Date: <Current date time>
Ensuite, la différence <date d'expiration> - <date heure actuelle> est utilisée comme Fraîcheur pour ce fichier.
3. La spécification HTTP/1.1, RFC 2616 (HTTP), recommande la présence de l'un ou l'autre des en-têtes de message http comme décrit à (1) ou (2). Si le serveur n'envoie pas les deux (1) ou (2) dans sa réponse http, vous pouvez prendre 10 % de la différence entre Date et Dernière modification des en-têtes de message :
Last-Modified: <last-modified date time> Date: <Current date time>
Ainsi, FreshTime pour ce fichier est calculé comme suit :
FreshTime = 10% x ((Last-Modified) - (Date))
4. Enfin, c'est à ce moment que l'interface de ligne de commande de mise à jour du cache entre en jeu. L'interface de ligne de commande permet à l'utilisateur d'attribuer une valeur heuristique FreshTime aux fichiers en tant que valeur provisoire au cas où aucun des en-têtes de message ci-dessus (1)-(3) ne serait présent.
c5400-02(config)#http client cache refresh ?
<1-864000> Time value in seconds
La valeur d'actualisation par défaut est de 86 400 secondes (24 heures).
Note: L'actualisation du cache du client http configuré n'a aucun effet sur les fichiers lorsque l'un des en-têtes de message (1) - (3) est présent.
Note: Cette CLI, si elle est effective, n'est pas rétroactive. En d'autres termes, la valeur d'actualisation nouvellement configurée s'applique uniquement aux nouveaux fichiers entrants. Il n'a aucun effet sur les entrées déjà dans le cache.
Note: Le routeur n'actualise jamais automatiquement les fichiers périmés.
Les fichiers périmés ne sont actualisés qu'en fonction des besoins. Pourquoi le routeur dépense-t-il ses précieux cycles CPU pour mettre à jour les fichiers dans le cache sans savoir si ou quand ces fichiers seront utilisés, alors que le processeur est nécessaire pour d'autres services urgents ?
Cela signifie qu'une entrée en cache obsolète peut rester longtemps dans le cache jusqu'à ce qu'elle soit supprimée pour libérer de la place pour une nouvelle copie du même fichier, ou pour un autre fichier qui a juste besoin de son espace mémoire dans le cache. Parfois, une entrée en cache obsolète peut encore être utilisable, si son âge n'a pas dépassé la valeur MaxStale spécifiée par l'application.
En bref, qu'une entrée mise en cache soit périmée ou encore utilisable, peut être calculée à l'aide de ces comparaisons simples :
- 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
Indique que le client est prêt à accepter une réponse qui a dépassé son délai d'expiration. Si une valeur est attribuée à max-stale, le client est prêt à accepter une réponse qui a dépassé son délai d'expiration d'au plus quelques secondes. Si aucune valeur n'est attribuée à max-stale, le client est prêt à accepter une réponse de type obsolète quel que soit son âge.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Comme mentionné précédemment, une entrée en cache obsolète est supprimée par son propriétaire selon les besoins, lorsque :
L'entrée mise en cache devient obsolète ; et
Son nombre de références est zéro (0), c'est-à-dire que personne n'utilise cette entrée mise en cache ; et
Son espace mémoire est nécessaire pour laisser de la place aux autres entrées
Cela signifie que le client http et le lecteur multimédia IVR doivent gérer et contrôler leurs entrées mises en cache de cette manière dans les modes non-diffusion et diffusion, respectivement. Que se passe-t-il si le client http doit nettoyer certaines entrées obsolètes pour récupérer de l'espace dans le pool de mémoire cache, mais qu'il n'est pas le propriétaire de ces fichiers ? Cela devient la responsabilité de l'analyseur d'arrière-plan du cache client http.
Le navigateur d'arrière-plan du cache client http se réveille toutes les 5 minutes. Si la mémoire totale utilisée pour les entrées mises en cache dépasse le seuil de 70 % de la taille du pool de mémoire cache configurée, le ager va parcourir chaque entrée mise en cache. Si l'entrée est encore fraîche, elle le laissera tranquille. Si l'entrée est obsolète et n'a aucune référence à elle, c'est-à-dire le nombre de réf = 0, le client http supprime l'entrée de lui-même car il est le propriétaire légitime de cette entrée. Si l'entrée obsolète contient un nombre de références 1 et qu'elle n'a aucun parent ou enfant lié à celui-ci, ce qui signifie que le fichier n'est pas en cours de téléchargement d'actualisation, le client http rappelle pour avertir le Lecteur Windows Media de libérer cette entrée obsolète.
Parfois, il peut être souhaitable ou nécessaire de télécharger manuellement un fichier audio dans le routeur. À l'heure actuelle, on nous dit déjà que le routeur n'accède pas automatiquement au serveur http pour actualiser les entrées obsolètes mises en cache. Ces entrées sont actualisées uniquement lorsqu'elles sont nécessaires. Un téléchargement manuel peut résoudre ce problème.
Un autre scénario qu'un téléchargement manuel peut être utile est de précharger une invite audio volumineuse en mode non continu. Cette opération peut être effectuée avant la réception du premier appel, de sorte que l'appelant n'ait aucun retard de chargement de l'invite.
Afin de télécharger manuellement un fichier audio particulier, exécutez la commande CLI suivante :
chargement de l'invite audio <url>
Le <url> est l'emplacement du fichier audio sur le serveur. Bien sûr, le cache du client http doit être correctement configuré pour enregistrer ce fichier dans le cache.
Note: Si l'invite <url> est active, c'est-à-dire qu'elle est en cours d'exécution, cette interface de ligne de commande ne prend pas effet.
Assurez-vous également que la date et l'heure entre la passerelle et le serveur multimédia HTTP sont synchronisées. C'est une nécessité.
Avertissement : N'utilisez pas le cache du client http dans le GW VXML. Si cette commande est appelée sur VXML GW très chargé/actif, il est connu qu'elle cause des problèmes, de la corruption de la mémoire et des plantages. Fondamentalement, l'utilisation de clear ip http client cache all n'est pas recommandée. Ce qu'il fait, c'est qu'il actualise toutes les entrées du cache, et ce qui se passe, c'est qu'il crée et supprime des noeuds de la liste de liens du cache, ce qui cause quelques problèmes. La commande est en cours de suppression de Cisco IOS®. La commande recommandée est set http client cache stale, ce que cette commande fait est qu'elle actualise simplement la nouvelle partie du cache modifiée.