Visión general de Web Application Acceleration

Enumera y describe los conceptos asociados al servicio Web Application Acceleration.

Aceleración

Las aceleraciones son las que enlazan las políticas de aceleración de aplicaciones web a los equilibradores de carga. Al asociar una aceleración a una política de aceleración de aplicación web, está asignando un equilibrador de carga a esa política y las disposiciones de la política se aplican a las operaciones del equilibrador de carga

Almacenamiento en caché

Permite el almacenamiento en caché en el equilibrador de carga para reducir la latencia y evitar un aumento de la carga en los servidores backend.

Depuración de caché

Las cachés de uno o más equilibradores de carga que comprenden la aceleración se depuran de los datos.

Nota

La depuración de caché es una acción irreversible.

Compresión

La compresión es una opción al seleccionar el almacenamiento en caché. Las compresiones comprimen las respuestas del servidor backend antes de devolverlas al usuario de la aplicación web para reducir la cantidad de ancho de banda necesario. Esta compresión acelera el tránsito de las respuestas del servidor por la red. Actualmente sólo se admite el algoritmo de compresión GZIP.

Equilibradores de carga

Los equilibradores de carga determinan el enrutamiento de tráfico. Puede mejorar el rendimiento de los equilibradores de carga asignándoles políticas de aceleración de aplicaciones web mediante aceleraciones.

Política de aceleración de aplicación web

Las políticas de aceleración de aplicaciones web definen los parámetros para aplicar aceleraciones al tráfico web mediante el almacenamiento en caché y la compresión.

Web Application Acceleration es un servicio que puede acelerar el tráfico de los equilibradores de carga aplicando una combinación de almacenamiento en caché y compresión.

El almacenamiento en caché y la compresión se producen para cualquier respuesta de 200 a una solicitud GET o HEAD inferior al tamaño máximo de caché. El almacenamiento en caché y la compresión no se producen cuando están presentes las siguientes cabeceras:

• Cache-Control: no-cache

• Cache-Control: private

El almacenamiento en caché y la compresión pueden acelerar significativamente el tráfico en los equilibradores de carga. Sin embargo, el uso de estas funciones tiene las siguientes restricciones:

• Almacenamiento en caché

  • Solo las solicitudes HEAD y GET se almacenan en caché.

  • Solo las respuestas que devuelven el código de estado HTTP 200 se almacenan en caché.

  • Es posible que el contenido en caché no se mantenga actualizado con el contenido de los servidores respaldados hasta que la caché caduque o se depure.

  • El contenido se almacena en caché hasta que caduca o se depura incluso si el archivo se elimina del servidor backend.

  • Los servidores backend pueden obtener un aumento drástico del tráfico cuando se produce alguno de los siguientes eventos:

    • Varios elementos de caché caducan al mismo tiempo.

    • La caché se depura.

    • El servicio Web Application Acceleration está desactivado.

  • El tamaño máximo de la caché es de 100 MB. Una vez alcanzado este tamaño máximo, el servicio Web Application Acceleration elimina los recursos a los que se ha accedido menos veces hasta que ya no se excede el tamaño máximo.

    No puede almacenar en caché archivos de más de 100 MB.

    Nota
    
    

    Puede solicitar que se aumente el tamaño de la caché del servicio Web Application Acceleration. Consulte Solicitud de aumento del límite de servicio para obtener más información.

  • Las respuestas que devuelven la cabecera Set-Cookie no se almacenan en caché.

  • Oracle recomienda no almacenar en caché páginas dinámicas porque pueden filtrar información.

• Compresión:

  • Si desactiva la compresión cuando se activó anteriormente, es posible que los usuarios de las aplicaciones web experimenten una mayor latencia de solicitudes a medida que aumentan las descargas de datos.

Por defecto, la respuesta se almacena en caché durante 10 minutos. Puede configurar el tiempo de caché definiendo una de las cabeceras de respuesta de tiempo de caché en la respuesta devuelta por el servidor backend.

Se admiten las siguientes cabeceras de tiempo de caché:

• Cache-Control: seleccione las directivas max-age o s-maxage para definir el tiempo de caché. Ambas directivas indican el tiempo en segundos que la respuesta se almacena en la caché. Por ejemplo, Cache-Control: max-age=300 almacena en caché la respuesta durante 300 segundos. Si las directivas max-age y s-maxage están presentes, s-maxage tiene prioridad.

• Vence: especifique la fecha/hora después de la cual la respuesta se considera caducada. Utilice solo el formato de fecha HTTP (RFC2616) para especificar la fecha/hora. Por ejemplo, Expires: Mon, 20 Feb 2023 12:45:26 GMT almacena en caché la respuesta hasta esta fecha.

• X-Accel-Expires: especifique el tiempo de almacenamiento en caché de una respuesta en segundos. El valor cero (0) desactiva el almacenamiento en caché para una respuesta. Si el valor empieza por el prefijo @, define un tiempo absoluto en segundos desde Epoch. El tiempo de respuesta se almacena en caché hasta este momento. Por ejemplo, X-Accel-Expires: 300 almacena en caché la respuesta durante 300 segundos. X-Accel-Expires: @1676901818 almacena en caché la respuesta hasta el lunes, 20 de febrero de 2023, 14:03:38 GMT.

Configure el tiempo de caché según la duración esperada de una respuesta en caché. Si el contenido es estático (inmutable), configure la caché durante un período de tiempo prolongado. Si el contenido cambia con frecuencia, configure la caché durante un período de tiempo más corto. Para obtener mejores resultados, almacene en caché el tiempo de caducidad para que coincida con el tiempo de actualización de contenido.