Présentation de Web Application Acceleration

Répertorie et décrit les concepts associés au service Web Application Acceleration.

Accélération

Les accélérations sont ce qui lie les stratégies d'accélération d'application Web aux équilibreurs de charge. Lorsque vous associez une accélération à une stratégie d'accélération d'application Web, vous affectez un équilibreur de charge à cette stratégie et les dispositions de cette stratégie sont appliquées aux opérations de l'équilibreur de charge.

Mise en cache

Permet la mise en cache au niveau de l'équilibreur de charge afin de réduire la latence et d'éviter une augmentation de la charge sur les serveurs back-end.

Purge du cache

Les caches d'un ou plusieurs équilibreurs de charge comprenant l'accélération sont purgés des données.

Remarque

La purge du cache est une action irréversible.

Compression

La compression est une option lors de la sélection de la mise en cache. La compression compresse les réponses du serveur back-end avant de les renvoyer à l'utilisateur de l'application Web afin de réduire la bande passante requise. Cette compression accélère le transit des réponses du serveur sur le réseau. Actuellement, seul l'algorithme de compression GZIP est pris en charge.

Equilibreurs de charge

Les équilibreurs de charge déterminent le routage du trafic. Vous pouvez améliorer les performances des équilibreurs de charge en leur affectant des stratégies d'accélération d'application Web via des accélérations.

Stratégie d'accélération d'application Web

Les stratégies d'accélération d'application Web définissent les paramètres d'application des accélérations au trafic Web à l'aide de la mise en cache et de la compression.

Web Application Acceleration est un service qui peut accélérer le trafic sur vos équilibreurs de charge en appliquant une combinaison de mise en cache et de compression.

La mise en cache et la compression se produisent pour toute réponse 200 à une demande GET ou HEAD inférieure à la taille maximale du cache. La mise en cache et la compression ne se produisent pas lorsque les en-têtes suivants sont présents :

• Cache-Control: no-cache

• Cache-Control: private

La mise en cache et la compression peuvent considérablement accélérer le trafic sur vos équilibreurs de charge. Toutefois, l'utilisation de ces fonctionnalités présente les contraintes suivantes :

• Mise en cache

  • Seules les demandes HEAD et GET sont mises en cache.

  • Seules les réponses renvoyant le code de statut HTTP 200 sont mises en cache.

  • Le contenu mis en cache peut ne pas rester à jour avec le contenu sur les serveurs soutenus jusqu'à ce que le cache expire ou soit purgé.

  • Le contenu est mis en cache jusqu'à ce qu'il expire ou soit purgé, même si le fichier est enlevé du serveur back-end.

  • Les serveurs back-end peuvent augmenter considérablement le trafic lorsque l'un des événements suivants se produit :

    • Plusieurs éléments de cache expirent en même temps.

    • Le cache est purgé.

    • Le service Web Application Acceleration est désactivé.

  • La taille maximale du cache est de 100 Mo. Une fois cette taille maximale atteinte, le service Web Application Acceleration supprime les ressources qui ont été consultées le moins de fois jusqu'à ce que la taille maximale ne soit plus dépassée.

    Vous ne pouvez pas mettre en cache les fichiers de plus de 100 Mo.

    Remarque
    
    

    Vous pouvez demander à augmenter la taille du cache de votre service Web Application Acceleration. Pour plus d'informations, reportez-vous à Demande d'augmentation de limite de service.

  • Les réponses renvoyant l'en-tête Set-Cookie ne sont pas mises en cache.

  • Oracle vous recommande de ne pas mettre en cache les pages dynamiques car elles peuvent générer des fuites d'informations.

• Compression :

  • Si vous désactivez la compression alors qu'elle était précédemment activée, la latence des demandes des utilisateurs de vos applications Web risque d'augmenter au fur et à mesure que leurs téléchargements de données augmentent.

Par défaut, la réponse est mise en cache pendant 10 minutes. Vous pouvez configurer le temps de cache en définissant l'un des en-têtes de réponse du temps de cache dans la réponse renvoyée par le serveur back-end.

Les en-têtes d'heure de cache suivants sont pris en charge :

• Cache-Control : sélectionnez les directives max-age ou s-maxage pour définir l'heure du cache. Les deux directives indiquent la durée en secondes pendant laquelle la réponse est stockée dans le cache. Par exemple, Cache-Control: max-age=300 met en cache la réponse pendant 300 secondes. Si les directives max-age et s-maxage sont présentes, s-maxage est prioritaire.

• Expire : indiquez la date/heure après laquelle la réponse est considérée comme expirée. Utilisez uniquement le format de date HTTP (RFC2616) pour indiquer la date/heure. Par exemple, Expires: Mon, 20 Feb 2023 12:45:26 GMT met en cache la réponse jusqu'à cette date.

• X-Accel-Expires : indiquez le temps de mise en cache d'une réponse en secondes. La valeur zéro (0) désactive la mise en cache pour une réponse. Si la valeur commence par le préfixe @, elle définit un temps absolu en secondes depuis Epoch. Le temps de réponse est mis en mémoire cache jusqu'à ce moment. Par exemple, X-Accel-Expires: 300 met en cache la réponse pendant 300 secondes. X-Accel-Expires: @1676901818 met en mémoire cache la réponse jusqu'au lundi 20 février 2023 14:03:38 GMT.

Configurez le temps de cache en fonction de la durée de vie attendue d'une réponse mise en cache. Si le contenu est statique (inaltérable), configurez le cache pendant une longue période. Si le contenu change souvent, configurez le cache pour une période plus courte. Pour obtenir de meilleurs résultats, mettez en cache l'heure d'expiration afin qu'elle corresponde à l'heure de mise à jour du contenu.