Almacenamiento en caché de alto rendimiento con NGINX y NGINX Plus

Esta publicación es una adaptación de un seminario web de Owen Garrett, presentado por Andrew Alexeev.

Tabla de contenido

INTRODUCCIÓN

Almacenamiento en caché de contenido y NGINX

Control del almacenamiento en caché

Preguntas y respuestas

0:00 Introducción

Andrés Alexeev : Bienvenido a nuestro último seminario web; mi nombre es Andrew. NGINX fue escrito por Igor Sysoev con la idea de ayudar a que los sitios web del mundo funcionen más rápido, tengan mayor capacidad de respuesta y sean fácilmente escalables. Hoy en día, NGINX impulsa más del 30 % de los sitios más importantes y más del 20 % de todos los sitios web de Internet. [ Editor: Estas estadísticas se aplicaron cuando se realizó el seminario web en mayo de 2014; consulte los valores actuales aquí ]. Espero que el contenido de este seminario web le resulte útil y aplicable a su entorno NGINX actual o planificado.

Ahora permítanme presentarles a Owen Garrett. Owen es responsable del desarrollo de productos en NGINX. Hoy, hablará sobre cómo aplicar potentes mecanismos de almacenamiento en caché en NGINX para liberar a su aplicação de la carga de generar contenido repetitivo una y otra vez.

1:22 Acerca de este seminario web

Owen Garrett : Gracias, Andrew, y amigos, muchas gracias por acompañarnos durante los próximos 45 o 50 minutos. Hablaré sobre cómo funciona NGINX con respecto al almacenamiento en caché de contenido , veremos algunas de las formas en que puede mejorar el rendimiento, profundizaremos un poco en cómo funciona realmente el almacenamiento en caché de contenido para que esté equipado para depurar y diagnosticar lo que está sucediendo dentro de NGINX, y terminaré con algunos consejos y sugerencias inteligentes para brindarle un control realmente preciso sobre lo que hace NGINX con el contenido que se puede almacenar en caché.

Todos apuntan a las mismas razones principales, como lo describió Andrew, para quitarle a sus servidores ascendentes la carga de generar contenido repetitivo para que puedan ejecutar las aplicações que su negocio realmente necesita. Aumente más allá de esos servidores, brindándole a sus usuarios finales un mejor nivel de servicio y aumentando la confiabilidad de su servicio frente a grandes picos de tráfico de Internet y, potencialmente, fallas de los servidores ascendentes.

2:17 Principios básicos del almacenamiento en caché de contenido

Antes de analizar la configuración de implementación de NGINX, me gustaría repasar rápidamente cómo funciona básicamente el almacenamiento en caché de contenido para que todos comencemos desde la misma página, desde la misma base de información central.

2:35 Principios básicos

El principio básico del almacenamiento en caché de contenido es descargar el trabajo repetitivo de los servidores ascendentes. Cuando el primer usuario solicita un elemento de contenido en el sitio web (ilustrado por el ícono azul y las líneas azules), su solicitud HTTP se reenvía a NGINX y desde allí al servidor ascendente en gris en el lado derecho.

La respuesta se reenvía al usuario remoto, pero si se puede almacenar en caché (y hablaremos de lo que eso significa en breve), NGINX almacena una copia de esa respuesta. Cuando otro usuario, el tipo naranja, aparece y solicita el mismo contenido, entonces NGINX puede servirlo directamente desde su caché local en lugar de falsificar la solicitud desde el servidor ascendente.

Este principio básico de almacenar contenido almacenable en caché e inmutable lo utiliza su navegador web, una CDN, los sitios a los que accede, las CDN que aprovechan y NGINX en otros dispositivos. Funciona como un caché de proxy inverso , generalmente implementado en el centro de datos o en la nube junto a los servidores de origen que alojan su contenido web y aplicações web.

3:59 Mecánica del almacenamiento en caché HTTP

El servidor de origen declara la capacidad de almacenamiento en caché del contenido utilizando uno o más de varios encabezados de respuesta HTTP bien conocidos y comprendidos. Por supuesto, los servidores de almacenamiento en caché pueden optar por ignorar, anular o cambiar este comportamiento. Pero para entender el almacenamiento en caché de contenido configurado, es necesario comenzar con una buena comprensión de la forma en que un servidor de origen indicará que el contenido se puede almacenar en caché, que no cambia y que la copia [en caché] tiene una duración determinada.

El almacenamiento en caché de contenido comenzó con un encabezado de respuesta HTTP simple llamado Expires . El servidor de origen presentaría algún contenido y declararía que dicho contenido sería válido hasta la fecha indicada en el encabezado Expires . Ese método fue rápidamente reemplazado por un método más efectivo y más flexible: el encabezado Cache-Control .

Expires es un tanto complicado de utilizar; es ineficiente. Las fechas deben formatearse y analizarse correctamente, mientras que Cache-Control es mucho más optimizado y está más alineado con las necesidades y la velocidad de los cachés de contenido. Cache-Control declara el contenido como público o privado y, en el caso de que sea público, declara una edad máxima : la cantidad de segundos que se puede almacenar en caché antes de que el objeto de almacenamiento en caché necesite volver a solicitar ese contenido.

El tercer encabezado que controla directamente el almacenamiento en caché es X-Accel-Expires . Este encabezado es especial para NGINX; sólo NGINX lo entiende y se utiliza si desea anular el comportamiento de los encabezados anteriores e indicarle a NGINX directamente con precisión durante cuánto tiempo debe almacenarse en caché un elemento de contenido.

Hay situaciones en las que puede querer que el navegador web almacene en caché el contenido durante un largo período de tiempo, pero prefiere que el caché proxy (NGINX ubicado frente al servidor de origen) lo almacene en caché durante un período de tiempo más corto para que los cambios se reflejen más rápidamente y se envíen a nuevos clientes, mientras que los clientes antiguos no vuelvan a solicitar el contenido cuando no lo necesitan.

Sin embargo, ese método también se puede implementar utilizando los dos últimos encabezados. Un servidor de origen puede declarar cuándo se modificó por última vez un elemento de contenido y puede declarar algo llamado ETag (etiqueta de entidad): una cadena opaca, a menudo un valor hash, que identifica ese contenido.

Los clientes pueden luego realizar solicitudes utilizando GET condicionales. Pueden incluir un encabezado If-Modified-Since o If-None-Match en su solicitud. Al hacer eso, el cliente declara que tiene una versión en caché del contenido que se modificó por última vez en una fecha particular o que tiene una ETag particular. Si la versión más reciente que tiene el servidor coincide con la versión que tiene el cliente, entonces el servidor responde simplemente con un 304No modificado . Esta es una respuesta rápida que ahorra ancho de banda de red y permite al cliente verificar a su gusto si la copia en caché del contenido aún es válida.

Estos cinco encabezados definen desde la perspectiva de un servidor de origen cómo se puede almacenar en caché el contenido: su validez, su actualidad y, en términos de ETag , los detalles del contenido en sí.

7:46 ¿Qué almacena en caché NGINX?

Los cachés proxy como NGINX son relativamente libres de interpretar cuán estrictamente cumplirán con esos encabezados. Está claro que no deberían almacenar en caché algo que no se puede almacenar en caché, pero, por supuesto, no tienen la obligación de almacenar en caché algo si el servidor de origen dice que se puede almacenar en caché.

El comportamiento básico de NGINX es almacenar en caché todas las solicitudes GET y HEAD que el servidor de origen indica como almacenables en caché, siempre que no haya encabezados Set-Cookie en la respuesta. Esto se debe a que los encabezados Set-Cookie generalmente incluyen datos únicos específicos para cada solicitud y, por defecto, no sería apropiado almacenar en caché ese valor.

NGINX almacena en caché cada recurso mediante una clave particular: una clave de caché. Todas las solicitudes que generen la misma clave de caché se satisfacerán con el mismo recurso. De forma predeterminada, la caché se asigna a la URL sin procesar o, en la configuración, a la cadena ilustrada en esta diapositiva [ $scheme$proxy_host$uri$is_args$args ]. En el momento en que NGINX almacena en caché el contenido, [el tiempo de validez] se define (en orden de preferencia) por el encabezado X-Accel-Expires si está presente o el encabezado Cache-Control o el encabezado Expires heredado.

Puede configurar NGINX para enmascarar algunos de estos encabezados o para proporcionar un tiempo de caché fijo en su lugar, completamente independientemente de lo que diga el servidor de origen. Como referencia, RFC 2616 define el comportamiento deseado de un caché proxy con respecto a HTTP.

Esto le dará una breve idea de la universalidad del almacenamiento en caché y el comportamiento básico predeterminado de NGINX al almacenar en caché contenido que generalmente es seguro almacenar en caché, con el fin de acelerar su sitio web y aliviar la carga de sus servidores de origen.

9:55 NGINX en funcionamiento

Ahora echemos un pequeño vistazo a NGINX en funcionamiento. Es realmente muy fácil configurar NGINX para habilitar el almacenamiento en caché de contenido.

10:06 Configuración de NGINX

Son un par de líneas en el archivo de configuración de NGINX: una para crear un caché en el disco con un determinado conjunto de parámetros que declaran cómo se disponen los archivos, el tiempo de expiración [para los objetos en ese caché] y el tamaño de ese caché. Luego, la segunda, la directiva proxy_cache , está asociada con un proxy NGINX y le indica que el contenido (resultados, respuestas) debe almacenarse en caché en un caché con nombre.

Entonces, aquí he creado un caché llamado uno ; tiene un tamaño de 10 MB en memoria para metadatos, pero un tamaño ilimitado en disco para el contenido almacenado en caché. El contenido se almacena en caché y luego se recupera si ha estado inactivo durante 60 minutos. Ese caché llamado uno lo utiliza nuestro servidor predeterminado. Estas dos [directivas], proxy_cache_path y proxy_cache , son suficientes para permitir un almacenamiento en caché confiable y consistente para un servidor proxy en NGINX.

11:14 Proceso de almacenamiento en caché

El proceso que NGINX realiza cuando recibe una solicitud y consulta un caché se define de la siguiente manera. Comenzamos leyendo una solicitud (cuadro superior izquierdo de esta diapositiva), ensamblando la clave de caché con la URI sin procesar y los otros parámetros que vamos a utilizar para identificar el recurso correspondiente a esa solicitud. Luego, verificamos el caché en el disco accediendo a los metadatos en la memoria para ver si tenemos una copia válida y nueva de la respuesta para esa solicitud.

Si lo hacemos, eso cuenta como un golpe. Luego NGINX puede responder directamente desde el caché. Responde desde la memoria caché sirviendo el contenido del disco exactamente como NGINX sirve el contenido estático. De esta forma obtienes el nivel de rendimiento, confiabilidad y escalabilidad para el que está diseñado NGINX. Con contenido estático, obtienes exactamente el mismo grado [de rendimiento] cuando sirves contenido desde el caché de contenido de NGINX.

Por otro lado, cuando comprobamos el caché, es posible que tengamos un error de caché. Esto significa que no tenemos el contenido en el caché, o que el contenido en el caché está desactualizado y necesita actualizarse. En el caso más simple, ese error significa que iríamos y solicitaríamos ese contenido al servidor de origen, recibiríamos la respuesta y verificaríamos si se puede almacenar en caché.

Si es así, lo transmitimos al disco tal como lo hace NGINX para cualquier respuesta grande manejada en modo proxy. Luego, una vez que [la respuesta] se transmite al disco, la copiamos en el caché y respondemos directamente desde el caché. Uno de los desafíos con este enfoque es si NGINX recibe múltiples solicitudes para el mismo contenido al mismo tiempo y todas resultan en un error.

NGINX normalmente reenviaría todas esas solicitudes al servidor de origen, lo que podría sobrecargarlo, en particular para las solicitudes que tardan mucho tiempo en generar respuestas. Entonces, por ese motivo, puedes utilizar un bloqueo de caché. La directiva proxy_cache_lock garantiza que si se actualiza un fragmento de contenido, solo se envíe una solicitud a la vez al servidor ascendente.

Entonces, en el escenario que describí, la primera solicitud iría al servidor ascendente, pero las solicitudes restantes para el mismo contenido se retendrán hasta que se haya entregado la respuesta y se haya insertado en el caché (momento en el que se pueden satisfacer todas las solicitudes), o se alcance un tiempo de espera [establecido por la directiva proxy_cache_lock_timeout ]: NGINX ha esperado lo suficiente para que el contenido regrese del servidor y, luego, en ese momento, las solicitudes que liberó se reenvían al servidor de origen.

Por lo tanto, proxy_cache_lock y timeout le brindan un control poderoso para garantizar que cuando tiene un sitio ocupado con muchas solicitudes para el mismo contenido, si ese contenido expira en el caché, no sobrecargue repentinamente el servidor de origen con múltiples solicitudes.

Hay un elemento más en el proceso de almacenamiento en caché en NGINX que no encaja claramente en este diagrama de flujo porque cubre casi todas las etapas del mismo. Esa es la capacidad configurada con la directiva proxy_cache_use_stale . En cualquier momento, si una de estas etapas falla por alguna razón, por ejemplo cuando estamos actualizando el contenido y alcanzamos un tiempo de espera o recibimos una mala respuesta del servidor ascendente o algún otro tipo de error, tenemos la opción de responder directamente desde el caché incluso si el contenido en caché está desactualizado.

Esta es una herramienta realmente poderosa en caso de que sus servidores ascendentes se vean abrumados por el tráfico o fallen debido a mantenimiento o un error catastrófico. Esto garantiza que NGINX pueda seguir entregando su contenido utilizando el contenido obsoleto del caché en lugar de devolver un mensaje de error al cliente.

15:32 El almacenamiento en caché no es solo para HTTP

El almacenamiento en caché en NGINX no es solo para HTTP. NGINX es mucho más que un simple proxy HTTP que reenvía solicitudes a servidores web ascendentes. Generalmente, estos servidores web ascendentes están ahí para interactuar con API como FastCGI o SCGI. NGINX puede hacerlo directamente mediante un proxy, muy similar al proxy HTTP.

NGINX puede emplear sus técnicas de almacenamiento en caché para servidores proxy HTTP , FastCGI , uWSGI y SCGI . Todos funcionan de manera muy similar al proxy HTTP, con cachés almacenados en el disco y respuestas directas, lo que evita la necesidad de utilizar proxy para estos servicios ascendentes.

NGINX también puede interactuar con un servidor memcached; este es un enfoque de almacenamiento en caché ligeramente diferente. En este caso, NGINX no almacena contenido directamente, utiliza memcached como proxy y depende de un agente externo para completar memcached con el contenido necesario. Esta puede ser otra herramienta útil y hay muchas formas de completar memcached desde un sitio externo si es necesario. Entonces, podría considerar esto como una forma de sembrar un caché para NGINX si ese es su requisito comercial.

17:10 Cómo entender lo que está pasando

El almacenamiento en caché puede ser potencialmente muy complejo si tienes una infraestructura grande con múltiples niveles, algunos haciendo almacenamiento en caché, algunos no, algunos generando contenido, otros no; entonces puede ser todo un desafío comenzar a rastrear lo que está sucediendo (de dónde proviene el contenido) y diagnosticar y depurar cualquier problema que encuentres. En NGINX lo hacemos lo más fácil posible para usted.

17:38 Instrumentación de caché

Con cierta instrumentación sofisticada, tienes la capacidad de controlar la instrumentación de forma dinámica para rastrear de dónde proviene el contenido, dónde está almacenado en el caché y cuál es el estado del caché.

El primer paso es la variable $upstream_cache_status , que se calcula para cada solicitud a la que NGINX ha respondido, ya sea desde la caché o no. Y agrega continuamente el valor de esa variable a tu respuesta usando la directiva add_header . Convencionalmente, colocamos ese valor en un encabezado X-Cache-Status en la respuesta. Puede tomar uno de siete valores diferentes, declarando cómo se presentó ese contenido. Ya sea que haya pasado por alto el caché, ya sea que provenga de una revalidación, ya sea que haya sido un éxito.

Éste es el primer paso para intentar comprender de dónde provienen sus respuestas. ¿Provienen del caché NGINX local o de un servidor ascendente? Y puede inspeccionar ese encabezado de respuesta de diferentes maneras: desde la línea de comando usando herramientas como curl , o muy comúnmente en su navegador web usando depuradores interactivos.

Por supuesto, es posible que no desees declarar ese valor a todos tus usuarios finales. Será mejor que sea selectivo en cuanto a cuándo insertar ese valor en la respuesta del encabezado.

19:08 Instrumentación de caché (cont.)

El lenguaje de configuración de NGINX le brinda la flexibilidad de ser selectivo. Este ejemplo muestra sólo una de las muchas maneras en que puedes hacer esto. Tomamos la dirección remota y si resulta ser localhost, entonces colocaremos $upstream_cache_status en una variable temporal ( $cache_status ). Finalmente, cuando devolvemos una respuesta, colocamos una variable temporal en la respuesta.

De esta manera, solo las solicitudes de direcciones IP selectivas verán el valor de la variable $upstream_cache_status . También puedes hacer muchas otras cosas; en breve veremos cómo se almacena el contenido en el disco. Puede incluir la clave que se utiliza para calcular la ubicación en el disco en la respuesta. Puede colocar todo tipo de parámetros en la respuesta para ayudarlo a diagnosticar el caché mientras se ejecuta.

20:09 Estado de la caché

NGINX Plus , nuestra versión comercial de NGINX, ofrece una serie de funciones adicionales que ayudan con casos de uso como el almacenamiento en caché. NGINX Plus es una versión de NGINX con soporte comercial creada por nuestro equipo de ingeniería en Moscú y ejecutada a través de un amplio conjunto de pruebas de regresión para garantizar su correcto funcionamiento.

NGINX Plus también contiene una serie de características dirigidas a empresas que buscan utilizar NGINX como proxy inverso y equilibrador de carga. Funciones relacionadas con el equilibrio de carga, controles de estado y transmisión de video avanzada. Y en el contexto de esto, características en torno a estado extendido, mejores diagnósticos y visualización de lo que está sucediendo en NGINX.

[Editor: la diapositiva anterior y el párrafo siguiente se han actualizado para hacer referencia a la API NGINX Plus , que reemplaza y deja obsoleto el módulo de estado separado que se analizó originalmente aquí].

Para una demostración, puede acceder a demo.nginx.com/dashboard.html y verá una página web que muestra los datos de estado publicados desde NGINX Plus mediante la API de NGINX Plus . Si ejecuta el comando curl indicado, verá los datos JSON sin procesar, tomados directamente del binario de NGINX Plus (aquí se canalizan a la utilidad jq para colocar cada elemento en su propia línea y con sangría jerárquica).

En esos datos JSON encontrarás datos en tiempo real sobre el estado de cada uno de los cachés en tu implementación de NGINX Plus. Esto, junto con la variable $upstream_cache_status y las otras formas en que puede instrumentar el caché, le brindan una muy buena descripción general de cómo NGINX almacena en caché el contenido y le permite profundizar en las solicitudes individuales, para determinar si esa solicitud provino del caché o no y el estado actual dentro del caché.

21:57 Cómo funciona el almacenamiento en caché de contenido en NGINX

Ahora bien, después de haber visto cómo podemos examinar el almacenamiento en caché de contactos desde fuera, veámoslo desde dentro. ¿Cómo funciona dentro de NGINX? Como mencioné anteriormente, el caché de contenido en NGINX funciona de la misma manera que se manejan los archivos en el disco. Obtienes el mismo rendimiento, la misma confiabilidad, las mismas optimizaciones del sistema operativo cuando sirves contenido desde nuestro caché de contenido que cuando sirves contenido estático: el rendimiento por el que NGINX es reconocido.

22:40 Cómo funciona

El caché de contenido se almacena en el disco en un caché persistente. Trabajamos en conjunto con el sistema operativo para intercambiar ese caché de disco en memoria, brindando sugerencias al caché de página del sistema operativo sobre qué contenido debe almacenarse en la memoria. Esto significa que cuando necesitamos servir contenido desde el caché, podemos hacerlo extremadamente rápido.

Los metadatos alrededor del caché, información sobre lo que hay allí y su tiempo de expiración, se almacenan por separado en una sección de memoria compartida en todos los procesos NGINX y siempre están presentes en la memoria. De esta forma, NGINX puede consultar y buscar en el caché de forma extremadamente rápida; solo necesita ir al caché de la página cuando necesita extraer la respuesta y entregársela al usuario final.

Veremos cómo se almacena el contenido en el caché, veremos cómo ese caché persistente se carga en procesos de trabajo NGINX vacíos durante el inicio, veremos parte del mantenimiento que NGINX realiza automáticamente en el caché y finalizaremos viendo cómo se puede podar manualmente el contenido del caché en situaciones particulares.

23:53 ¿Cómo se almacena el contenido en caché?

Recordarás que el caché de contenido se declara mediante una directiva llamada proxy_cache_path . Esta directiva especifica la cantidad de parámetros: dónde se almacena el caché en su sistema de archivos, el nombre del caché, el tamaño del caché en la memoria para los metadatos y el tamaño del caché en el disco. En este caso hay un caché de 40 MB en el disco.

La clave para entender dónde se almacena el contenido es comprender la clave de caché: el identificador único que NGINX asigna a cada recurso almacenable en caché. De forma predeterminada, ese identificador se construye a partir de los parámetros básicos de la solicitud: el esquema, el encabezado del host , la URI y cualquier argumento de cadena.

Pero puedes ampliarlo si lo deseas usando cosas como valores de cookies o encabezados de autenticación o incluso valores que hayas calculado en tiempo de ejecución. Quizás desee almacenar versiones diferentes para los usuarios del Reino Unido y para los usuarios de los EE. UU. Todo esto es posible configurando la directiva proxy_cache_key .

Cuando NGINX maneja una solicitud, calculará la proxy_cache_key y a partir de ese valor calculará una suma MD5. Puedes replicarlo tú mismo usando el ejemplo de línea de comando que mostré más abajo en la diapositiva. Tomamos la clave de caché httplocalhost:8002/time.php y la bombeamos a través de md5sum . Tenga cuidado, cuando esté haciendo esto desde el shell, de no bombear una nueva línea también.

Esto calculará el valor hash MD5 que corresponde a ese contenido almacenable en caché. NGINX usa ese valor hash para calcular la ubicación en el disco donde debe almacenarse el contenido. Verá en proxy_cache_path que especificamos un caché de dos niveles con un directorio de un carácter y luego un directorio de dos caracteres. Extraemos esos caracteres del final de la cadena para crear un directorio llamado4 y un subdirectorio llamado 9b , y luego colocamos el contenido del caché (más los encabezados y una pequeña cantidad de metadatos) en un archivo en el disco.

Puede probar el almacenamiento en caché de contenido. Puede imprimir la clave de caché como uno de los encabezados de respuesta y puede pasarla a través de md5sum para calcular la correspondencia hash de ese valor. Luego puedes inspeccionar el valor en el disco para ver que realmente está allí y los encabezados que NGINX almacenó en caché, para entender cómo encaja todo esto.

26:36 Cargando caché desde el disco

Ahora que el contenido está almacenado en el disco y es persistente, cuando NGINX se inicia necesita cargar ese contenido en la memoria; o mejor dicho, necesita recorrer ese caché de disco, extraer los metadatos y luego cargarlos en la memoria en el segmento de memoria compartida utilizado por cada uno de los procesos de trabajo. Esto se hace mediante un proceso llamado cargador de caché .

Un cargador de caché se activa al iniciar y se ejecuta una vez, cargando metadatos en el disco en pequeños fragmentos: 100 archivos a la vez, en un entorno aislado de 200 ms, con una pausa de 50 ms en el medio y repitiendo hasta que haya recorrido todo el caché y haya llenado el segmento de memoria compartida.

Luego, el cargador de caché sale y no necesita volver a ejecutarse a menos que se reinicie o reconfigure NGINX y sea necesario reinicializar el segmento de memoria compartida. Puede ajustar el funcionamiento del cargador de caché, lo que puede ser apropiado si tiene discos muy rápidos y una carga liviana. Puedes hacer que se ejecute más rápido o quizás quieras reducirlo un poco si estás almacenando un caché con una gran cantidad de archivos y discos lentos y no quieres que el cargador de caché use cantidades excesivas de CPU cuando se inicia NGINX.

28:07 Administrar la caché de disco

Una vez que el caché está en la memoria y los archivos se almacenan en el disco, existe el riesgo de que los archivos en caché a los que nunca se accede permanezcan allí para siempre. NGINX los almacenará la primera vez que los vea, pero si no hay más solicitudes de un archivo, entonces [el archivo] simplemente permanecerá allí en el disco hasta que algo llegue y lo limpie.

Este algo es el administrador de caché ; se ejecuta periódicamente, purgando los archivos del disco a los que no se ha accedido dentro de un período de tiempo determinado y elimina archivos si el caché es demasiado grande y ha desbordado su tamaño declarado. Los elimina de la forma menos utilizada recientemente. Puede configurar esta operación utilizando parámetros en la directiva proxy_cache_path [directiva], tal como configura el cargador de caché:

• El tiempo de inactividad predeterminado es 10 minutos.
• El parámetro de tamaño máximo no tiene un límite predeterminado. Si impone un límite de tamaño máximo en la memoria caché, a veces puede superar ese límite, pero cuando se ejecuta el administrador de caché, eliminará los archivos menos utilizados recientemente para volver a colocarlo por debajo de ese límite.

29:22 Purga de contenido del disco

Finalmente, hay ocasiones en las que es posible que desees purgar contenido del disco. Desea encontrar un archivo y eliminarlo; es relativamente fácil hacerlo si conoce las técnicas que mencionamos anteriormente (ejecutar la clave de caché a través de md5sum o simplemente ejecutar un grep recursivo en el sistema de archivos para intentar identificar el archivo o los archivos que necesita eliminar).

Alternativamente, si está usando NGINX Plus, puede utilizar la capacidad de purga de caché integrada en ese producto. La capacidad de purga de caché le permite tomar un parámetro particular de la solicitud; generalmente usamos un método llamado PURGE como forma de identificar que es una solicitud de purga de caché.

La purga la gestiona un controlador especial NGINX Plus que inspecciona la URI y elimina del caché todos los archivos que coinciden con esa URI. Se puede añadir un asterisco como sufijo al URI para que se convierta en una raíz. En este caso, vamos a utilizar la capacidad de purga para eliminar todos los archivos que se entregan desde el puerto de host local 8001, pero, por supuesto, también puedes incluir subdirectorios.

Cualquiera sea el método que use, en cualquier momento puede eliminar con total seguridad archivos del caché en el disco o incluso ejecutar rm -rf en todo el directorio de caché. NGINX no se saltará ningún paso; continuará verificando la presencia de archivos en el disco. Si faltan, se produce un error de caché. Luego, NGINX recuperará el caché del servidor de origen y lo almacenará nuevamente en el caché del disco. Por lo tanto, siempre es seguro, confiable y estable si necesita borrar archivos individuales del caché.

31:27 Control del almacenamiento en caché

Entonces, hemos visto cómo funciona el almacenamiento en caché, hemos visto la implementación dentro de NGINX y hemos realizado un análisis profundo de cómo almacena archivos en el disco para obtener el mismo tipo de rendimiento que obtiene con contenido estático. Ahora vamos a ser un poco más inteligentes en cuanto al almacenamiento en caché.

Para sitios simples, puede activar el almacenamiento en caché y, en general, hará exactamente lo que debe hacer para seguir brindándole el nivel de rendimiento y el comportamiento de caché que desea. Pero siempre hay optimizaciones que realizar y a menudo hay situaciones en las que el comportamiento predeterminado no coincide con el comportamiento deseado.

Tal vez sus servidores de origen no estén configurando los encabezados de respuesta correctos o tal vez desee anular lo que están especificando dentro de NGINX. Hay una gran variedad de formas de configurar NGINX para ajustar el funcionamiento del almacenamiento en caché.

32:30 Almacenamiento en caché retardado

Puede retrasar el almacenamiento en caché. Esta es una situación muy común si tienes un gran corpus de contenido, gran parte del cual se accede solo una o dos veces por hora o por día. En ese caso, si tiene un folleto de su empresa que muy pocas personas leen, a menudo es una pérdida de tiempo intentar almacenar en caché ese contenido. El almacenamiento en caché retrasado le permite colocar una marca de agua. Solo almacenará una versión en caché de este contenido si se ha solicitado una cierta cantidad de veces. Hasta que no se alcance la marca de agua proxy_cache_min_uses , no se almacenará una versión en el caché.

Esto le permite ejercer una mayor discriminación sobre qué contenido va en su caché. El caché en sí es un recurso limitado, generalmente limitado por la cantidad de memoria que tiene en su servidor, porque querrá asegurarse de que el caché esté paginado en la memoria en la medida de lo posible. A menudo, desea limitar ciertos tipos de contenido y solo colocar las solicitudes populares en su caché.

La revalidación de caché es una característica que se agregó recientemente a NGINX Open Source y NGINX Plus. Modifica la capacidad If-Modified-Since de modo que cuando NGINX necesita actualizar un valor que ha sido almacenado en caché, no realiza un simple GET para obtener una nueva versión de ese contenido; realiza un GET condicional, que dice: "Tengo una versión almacenada en caché que se modificó en esta fecha y hora particulares".

El servidor de origen tiene la opción de responder con 304No modificado , lo que significa que la versión que tienes sigue siendo la versión más reciente que existe. Esto ahorra ancho de banda ascendente; el servidor de origen no tiene que reenviar contenido que no ha cambiado y también ahorra potencialmente en escrituras en disco. NGINX no tiene que transmitir ese contacto al disco y luego intercambiarlo en su lugar, sobrescribiendo la versión anterior.

34:45 Control del tiempo de caché

Tienes control detallado sobre cuánto tiempo debe almacenarse en caché el contenido. Muy a menudo, el servidor de origen servirá contenido con encabezados de caché que son apropiados para los navegadores: almacenamiento en caché a largo plazo con una solicitud relativamente frecuente para actualizar el contenido. Sin embargo, es posible que prefieras que el proxy NGINX esté ubicado directamente frente a tu servidor de origen para actualizar los archivos un poco más a menudo y detectar los cambios más rápidamente.

Hay un gran aumento en la carga si reduce el tiempo de espera de caché de los navegadores de 60 segundos a 10 segundos, pero hay un aumento muy pequeño en la carga si aumenta el tiempo de espera de caché en NGINX de 60 segundos a 10 segundos. Por cada solicitud, se agregarán cinco solicitudes más por minuto a sus servidores de origen, mientras que con los clientes remotos, todo depende de la cantidad de clientes con cosas similares activas en su sitio.

Por lo tanto, puedes anular la lógica y la intención que dice tu servidor de origen. Puede enmascarar o indicarle a NGINX que ignore ciertos encabezados: X-Accel-Expires , Cache-Control o Expires . También puede proporcionar un tiempo de caché predeterminado utilizando la directiva proxy_cache_valid en su configuración de NGINX.

36:18 Caché / No almacenar en caché

A veces, es posible que no se almacene en caché el contenido que el servidor de origen indica que es almacenable, o que se desee garantizar que se omita la versión del contenido almacenado en NGINX. Las directivas proxy_cache_bypass y proxy_no_cache ofrecen ese grado de control.

Puede usarlos como un atajo para indicar que si se configura alguno de un determinado conjunto de encabezados de solicitud, como la autorización HTTP, o si está presente un parámetro de solicitud, entonces desea omitir el caché, ya sea para actualizar automáticamente el caché en NGINX o simplemente omitirlo por completo y siempre recuperarlo del servidor de origen.

Por lo general, esto se hace para decisiones de almacenamiento en caché bastante complejas, donde se toman decisiones detalladas sobre los valores de las cookies y los encabezados de autorización para controlar qué se debe almacenar en caché, qué se debe recibir siempre del servidor de origen y qué nunca se debe almacenar en el caché de NGINX.

37:25 Múltiples cachés

Por último, para implementaciones de gran escala, es posible que desees explorar múltiples cachés dentro de una instancia NGINX individual, por un par de razones. Es posible que tenga diferentes políticas de caché para diferentes inquilinos en su proxy NGINX, dependiendo de la naturaleza de su sitio y de la importancia del rendimiento de ese sitio, incluso dependiendo del plan particular al que esté suscrito cada inquilino en una situación de alojamiento compartido.

O puede tener varios discos en el host NGINX y es más eficiente implementar un caché individual en cada disco. La regla de oro es minimizar la cantidad de copias de un disco a otro y esto se puede lograr fijando un caché a cada disco y fijando el archivo temporal de cada proxy que usa ese caché al disco correcto.

El funcionamiento estándar es que cuando NGINX recibe contenido de un proxy ascendente, transmitirá ese contenido al disco a menos que sea lo suficientemente pequeño y quepa en la memoria. Luego, una vez que ese contenido se transmite al disco, se moverá a la memoria caché. Esa operación es infinitamente más eficiente si la ubicación en el caché de los archivos temporales (el disco donde se almacenan los archivos temporales) es la misma que el disco donde se almacena el caché.

39:07 Revisión rápida: ¿Por qué almacenar en caché?

Entonces, hablamos sobre el almacenamiento en caché, hablamos sobre los métodos que usa NGINX, la implementación dentro de NGINX y las formas en que puedes ajustarlo. A medida que nos acercamos al final, hagamos un repaso rápido para recordarnos por qué es necesario almacenar en caché el contenido en primer lugar. NGINX se implementa en 114 millones de sitios web en todo el mundo y muchos de estos usuarios lo hacen por sus capacidades de aceleración web y almacenamiento en caché de contenido. [ Editor: Esta estadística corresponde a la fecha del seminario web, realizada en mayo de 2014 ].

39:44 ¿Por qué es importante la velocidad de la página?

Estas capacidades mejoran la velocidad de un sitio web (ofrecen a los usuarios finales un mejor nivel de experiencia) y la velocidad de una página web es muy, muy importante. Durante años y años, los analistas han estado monitoreando el comportamiento de los usuarios y han desarrollado lo que se conoce coloquialmente como la “regla de los N segundos”. Este es el tiempo que un usuario promedio está dispuesto a esperar para que la página se cargue y se visualice antes de aburrirse, impacientarse y irse a otro sitio web, a un competidor.

A medida que los estándares han mejorado y las expectativas de los usuarios se han vuelto cada vez más altas, el período que los usuarios están dispuestos a esperar es cada vez más corto. Se podría, mediante algunos cálculos ligeramente dudosos, extrapolar eso y concluir que los usuarios tendrán un nivel negativo de paciencia alrededor de 2016.

40:46 Google cambió las reglas

Pero en realidad la tecnología nos ha superado. Google lo ilustró gráficamente hace un par de años cuando presentó Google Instant Search. Ahora con Google, cuando escribes un término de búsqueda en un cuadro de búsqueda, incluso antes de que termines de escribir, Google te presenta resultados de búsqueda candidatos. Esto ilustra el enorme cambio en las expectativas sobre la Internet moderna. Como ha dicho el propio Google, “los usuarios ahora esperan que las páginas web reaccionen de la misma manera que lo hacen al pasar las páginas de un libro”: con la misma rapidez, fluidez y fluidez.

41:28 Los costos del bajo rendimiento

Si no logra alcanzar ese nivel de rendimiento, puede haber impactos significativos en el KPI que asocia con su sitio web o servicio web. Ya sean tasas de clics en anuncios: El propio Google descubrió que su tasa de clics en anuncios cayó un 20% cuando sus páginas de búsqueda tardaron medio segundo más en cargarse. Ya sean ingresos: en un intento deliberado de investigar el efecto de las páginas web lentas, Amazon aumentó deliberadamente la carga de la página en múltiplos de 100 ms y descubrió que los ingresos de los clientes afectados normalmente caían un 1 % por cada aumento de 100 ms.

Muchos otros analistas, sitios web e investigadores informaron efectos similares en las métricas de un sitio web, ya sea el tiempo en la página, la tasa de rebote, etc. Más recientemente, Google ha comenzado a tener en cuenta la velocidad de la página al calcular el ranking de páginas en los resultados de búsqueda. Lo que parece contar es el tiempo hasta el primer byte. Cuanto más tiempo se tarda en cargar el primer byte de una página, más penalizado será el ranking de su página. Un sitio web puede sufrir la situación de que ni siquiera se acceda a él porque aparece en la página tres, cuatro o cinco de los resultados de búsqueda de Google.

43:00 El almacenamiento en caché de NGINX le permite

Las capacidades de almacenamiento en caché de NGINX le permiten mejorar la experiencia del usuario final al reducir el tiempo hasta el primer byte y hacer que el contenido web se sienta más ágil y con mayor capacidad de respuesta.

NGINX le permite consolidar y simplificar su infraestructura web. NGINX no es solo un caché web independiente. NGINX incluye un servidor de origen web, incluye una puerta de enlace directa a API como FastCGI y, en NGINX Plus, incluye las capacidades para construir un equilibrador de carga y un controlador de entrega de aplicação sofisticados y listos para la empresa. Esto le permite consolidar múltiples componentes de red diferentes en su infraestructura web en un solo componente (NGINX o NGINX Plus), lo que le brinda soluciones más confiables, más fáciles de depurar y más rápidas.

NGINX le permite aumentar la capacidad del servidor quitando tareas repetitivas de los servidores ascendentes. De hecho, incluso para contenido que parece no poder almacenarse en caché (la página principal de un sitio de blogs, por ejemplo), tiene sentido almacenarlo en caché solo por un segundo en el proxy NGINX.

Cuando cien usuarios solicitan el mismo contenido en el mismo segundo, NGINX lo reducirá a una única solicitud al servidor de origen y les devolverá el contenido a esos usuarios desde su caché con la promesa de que ese contenido nunca estará desactualizado por más de un segundo. Eso suele ser más que suficiente para un sitio de blog o un sitio web similar, pero hace una gran diferencia en el rendimiento, tanto en la carga de los servidores ascendentes como en el gasto que tiene que hacer para administrar e implementar capacidad suficiente.

Por último, no olvide uno de los usos estratégicos de NGINX: aislarlo de fallas de los servidores ascendentes a través de la capacidad de “usar datos obsoletos” del caché proxy. Si funcionan con lentitud, si arrojan errores, si hay algún tipo de falla, entonces NGINX puede recurrir a la versión en caché local del contenido y continuar usándola hasta que sus servidores ascendentes se recuperen.

45:21 Reflexiones finales

El 38 % de los sitios web más activos del mundo utilizan NGINX principalmente por sus capacidades de aceleración web y almacenamiento en caché de contenido. [ Editor: Esta estadística se aplicó cuando se impartió el seminario web en mayo de 2014; consulte el valor actual aquí ]. Para obtener más soluciones y detalles, consulte los blogs y los resúmenes de características en nginx.com , que describen las capacidades de NGINX y NGINX Plus. Y eche un vistazo a nuestra lista de seminarios web , no solo los seminarios web futuros, sino también los seminarios web que se agregarán próximamente de eventos pasados en esta serie.

Y si desea investigar estas capacidades más a fondo, por supuesto existe la documentación y las soluciones que puede encontrar en nginx.org y nginx.com , pero nada supera descargarlo y probarlo. El producto de código abierto se puede encontrar en nginx.org , o el producto comercial compatible con funciones adicionales de equilibrio de carga, entrega de aplicação , administración y facilidad de uso en nginx.com .

Así que amigos, muchas gracias por su tiempo y su atención. Espero que esta presentación y recorrido sobre el almacenamiento en caché de contenido en NGINX haya sido útil y esclarecedor para muchos de ustedes.

Preguntas y respuestas

Comencemos a trabajar con las preguntas y veamos cómo lo hacemos.

47:20 Solicitudes de rango de bytes

Tenemos una pregunta sobre las solicitudes de rango de bytes. Las solicitudes de rango de bytes se utilizan cuando un cliente solicita un fragmento de contenido, pero solo necesita un subconjunto de ese contenido. Digamos que es un archivo de vídeo y el cliente solo necesita una parte del vídeo. O muy comúnmente, es un archivo PDF: el usuario ha leído los encabezados que tienen un índice en el archivo PDF y el cliente solo quiere descargar un determinado conjunto de páginas. ¿Cómo funciona eso en el caché de contenido de NGINX?

El proceso es el siguiente. Cuando NGINX recibe una solicitud de rango de bytes para un recurso y el recurso completo ya está en la memoria caché, NGINX responderá desde la memoria caché con el rango de bytes que el cliente ha solicitado. Si ese recurso no está en el caché, NGINX realizará una solicitud para todo el recurso al servidor ascendente y almacenará ese recurso en el caché. Actualmente, en ese punto NGINX no obedecerá la solicitud de rango de bytes y devolverá todo el recurso al cliente. En la mayoría de las situaciones, ese es un comportamiento aceptable.

Por ejemplo, si un cliente está descargando un documento PDF, su primera solicitud será de todos modos para el documento completo y solo si ese documento se transmite, el cliente cancela la conexión y comienza a realizar solicitudes de rango de bytes. Entonces, para el contenido almacenado en caché, NGINX respeta las solicitudes de rango de bytes. Para el contenido no almacenado en caché, NGINX recupera todo el contenido del servidor ascendente y devuelve todo el contenido al cliente en esa única instancia.

49:13 Revalidación de caché de proxy

Esta es una pregunta sobre la capacidad de revalidar la caché del proxy. Esta es la capacidad que permite a NGINX realizar un GET condicional al servidor ascendente para verificar si el contenido ha cambiado. El caso es:

¿La revalidación de caché de proxy tiene en cuenta los ETag o solo la fecha de modificación desde del contenido?

La respuesta es que simplemente verifica la fecha If-Modified-Since del contenido y, como punto en la práctica, generalmente es una buena práctica incluir siempre If-Modified-Since en sus respuestas y tratar las ETag como opcionales porque no se manejan de manera tan consistente o tan amplia como la fecha de "última modificación" que manejará en la respuesta.

50:07 Distribuir la caché en discos iguales

¿Es posible que NGINX equilibre la carga de su almacenamiento en caché para un solo sitio entre unos pocos discos iguales para lograr un mejor rendimiento?

Sí lo es. Requiere un poco de trabajo. El escenario típico es implementar un conjunto de discos sin RAID y luego implementar cachés individuales, uno anclado a cada disco. Requiere cierta configuración adicional y partición del tráfico. Si necesita ayuda para configurarlo, comuníquese con nuestra comunidad y allí trataremos su solicitud específica o, si utiliza NGINX Plus, comuníquese con nuestro equipo de soporte y estaremos encantados de ayudarlo.

50:50 Variar encabezado

¿NGINX tiene en cuenta el encabezado Vary en los errores de caché?

No, NGINX no maneja automáticamente los encabezados Vary . Si eso es un problema, es sencillo agregar el encabezado Vary a la clave de caché del proxy para que la clave única que se utiliza para almacenar la respuesta incluya el valor del encabezado Vary . Luego podrás almacenar varias versiones diferentes.

51:25 Primitivas de almacenamiento en caché

¿Se respetan todas las primitivas y directivas de almacenamiento en caché?

En general, sí. Hay un par de casos extremos, como los encabezados Vary , que no se respetan. En muchos casos, existe cierta flexibilidad en la interpretación de los requisitos de la RFC por parte de las distintas cachés. Siempre que ha sido posible, hemos optado por implementaciones fiables, consistentes y fáciles de configurar.

51:52 Encabezados y datos ascendentes

¿Se almacenan en caché tanto los encabezados ascendentes como los datos?

Sí lo son. Si recibe una respuesta de la memoria caché, se almacenan en caché tanto los encabezados como el cuerpo de la respuesta.

52:13 *‑Encabezados de codificación

Los valores del encabezado se almacenan en caché, al igual que el cuerpo de la respuesta, por lo que… Me sorprendería bastante si NGINX no funcionara correctamente con las distintas combinaciones de Transfer-Encoding . Accept-Encoding a menudo se implementa a través de un encabezado Vary , por lo que los comentarios anteriores sobre la necesidad de colocar encabezados Vary en su clave de caché se aplican allí (en el caso de clientes que no lo admiten).

52:56 SPDY

¿Funciona el almacenamiento en caché para SPDY?

Absolutamente. Puedes pensarlo como un proxy frontend para NGINX, aunque en la práctica está muy, muy profundamente entrelazado con el kernel de NGINX. Sí, SPDY funciona para el almacenamiento en caché.

53:15 Vary Header, Ronda 2

Aquí hay otra pregunta sobre el encabezado Vary . Para confirmar, si está usando respuestas de encabezado Vary y gzips, eche un vistazo a algunas de las discusiones en Trac o en nuestro sitio de la comunidad para encontrar soluciones a ese problema. El enfoque más común es incrustar el encabezado Vary en la clave de caché.

53:45 Velocidad de página

P: ¿PageSpeed utiliza almacenamiento en caché NGINX o su propio mecanismo de almacenamiento en caché?

Esa es una pregunta que deberás compartir con los desarrolladores de PageSpeed .

54:00 Otros cachés

P: ¿Cómo se comparan otros cachés de contenido con NGINX?

Las CDN son soluciones de almacenamiento en caché de contenido muy efectivas. Las CDN se implementan como un servicio; usted tiene un control más limitado sobre cómo se almacena en caché el contenido y cómo caduca dentro de ese almacenamiento, pero son una herramienta muy eficaz para acercar el contenido a los usuarios finales. NGINX es una herramienta muy eficaz para acelerar la aplicação web y, muy comúnmente, ambas se implementan juntas. En el caso de cachés independientes como Varnish: una vez más, son tecnologías muy capaces que funcionan de manera similar a NGINX en muchos aspectos. Uno de los beneficios de NGINX es que reúne puertas de enlace de aplicação de origen, almacenamiento en caché y equilibrio de carga en una única solución. Esto le brinda una infraestructura más simple y consolidada que es más fácil de implementar, más fácil de administrar, más fácil de depurar y más fácil de diagnosticar si tiene algún problema.

Para ver el webinar en el que se basa este post, accede al mismo aquí .

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso.