Almacenamiento en caché del proxy de NGINX: optimización del rendimiento y la memoria

Almacenamiento en búfer de NGINX determina la rapidez con la que tu proxy recibe las respuestas del servidor de origen, las almacena en el búfer y las envía a los clientes, sin saturar la memoria. Te mostraré cómo reducir la latencia, liberar las conexiones al backend lo antes posible y el Memoria mantenerlo bajo control.

Puntos centrales

Los siguientes aspectos fundamentales me ayudan a equilibrar adecuadamente el rendimiento y el consumo de memoria.

• Desacoplamiento La comunicación entre el cliente y el backend reduce el tiempo de conexión y aumenta el rendimiento.
• Tamaños de los búferes Selecciona «exactamente» para ahorrar RAM y evitar operaciones de E/S de disco.
• búferes ocupados limitar la memoria activa durante la transmisión.
• Excepciones en el streaming utilizarlo de forma fluida sin buffering.
• Monitoreo y las pruebas de carga garantizan la seguridad de cada modificación.

Cómo funciona el almacenamiento en búfer de proxy en NGINX

Utilizo el modo activo Almacenamiento en búfer, para que NGINX recoja rápidamente las respuestas del servidor de origen y, a continuación, las envíe de forma autónoma a los clientes. Esta separación reduce la Latencia en el backend, ya que la aplicación se procesa más rápido y cierra su conexión antes. Mientras los clientes se cargan a una velocidad variable, la capa proxy regula el envío desde la memoria RAM. Si los datos no caben por completo en la RAM, NGINX puede recurrir temporalmente a archivos y, de este modo, seguir transmitiendo la respuesta de forma fiable. Es precisamente este comportamiento el que estabiliza los sistemas sometidos a una gran carga con muchos usuarios simultáneos Conexiones.

Cuándo es mejor optar por el almacenamiento en búfer activo

En el caso de aplicaciones web clásicas, API con respuestas de tamaño medio o pilas de WordPress, ofrece Almacenamiento en búfer obtiene regularmente los mejores resultados. Libero el backend antes, mientras que NGINX se encarga del resto de la transferencia a redes de clientes que suelen ser heterogéneas. De este modo, aumenta la eficacia Rendimiento, sobre todo cuando hay muchas solicitudes en curso al mismo tiempo. Quien agrupe varios servicios detrás de un proxy inverso se beneficia además de una distribución controlada de la carga. Para cuestiones de arquitectura relacionadas con los proxies, me resulta útil una Arquitectura de proxy inverso, que separa claramente los roles y los límites.

Almacenamiento frente a E/S: el presupuesto adecuado

Equilibro la memoria RAM y los accesos al disco duro, porque unos búferes demasiado pequeños provocan E/S de disco y unos búferes demasiado grandes hacen que la memoria por conexión se sature. Son factores decisivos los tamaños típicos de las respuestas, las solicitudes en paralelo y la Velocidad del cliente. Lo ideal es que las respuestas pequeñas permanezcan íntegramente en la RAM, lo que permite a NGINX transmitirlas sin tiempos de espera a los destinatarios más lentos. Los cuerpos de gran tamaño pueden almacenarse en el disco, pero en ese caso me aseguro de utilizar unidades rápidas y de establecer límites para evitar un uso excesivo de E/S. Este equilibrio mantiene la Tiempos de respuesta baja y protege el sistema contra la presión de acumulación.

Resumen de las directivas y los valores de referencia

Configuraré de forma específica los parámetros principales para controlar la memoria y el comportamiento de envío. El primer búfer para los encabezados de respuesta se adjunta a proxy_buffer_size; evita errores debidos a encabezados demasiado grandes y evita transferencias innecesarias a la memoria externa. Los datos de respuesta propiamente dichos los distribuyo a través de proxy_buffers como pares de «número por tamaño», para que los cuerpos permanezcan íntegramente en la RAM, siempre que sea factible. Con proxy_busy_buffers_size Limito la cantidad de búferes ya asignados para el envío, con el fin de reducir el consumo de memoria activa. Para determinar los tamaños habituales, me baso en las páginas de memoria (4-32 KB) y en los perfiles de respuesta conocidos de mis aplicaciones.

directiva	Efecto	Valores típicos	Notas
proxy_buffering	Encendido/Apagado del almacenamiento en búfer	activado (por defecto)	Mantener activado para las aplicaciones web estándar; comprobarlo para la retransmisión en directo
proxy_buffer_size	Búfer de encabezado	8k–16k	Si es demasiado pequeño, se produce el error „upstream sent too big header“.“
proxy_buffers	Amortiguador corporal	8 de 16k, 16 de 16k	Vincular a los parámetros de respuesta y al paralelismo
proxy_busy_buffers_size	Límite del búfer de envío	32 k–128 k	Suficiente rendimiento sin ocupar memoria RAM
proxy_max_temp_file_size	Límite de disco	0–1 g	0 desactiva los archivos temporales
proxy_temp_path	Ruta para archivos temporales	Ruta del SSD	Guardar en un soporte de datos de alta velocidad

Perfiles orientados a la práctica y ejemplos de cálculos

Calculo el espacio de almacenamiento necesario por conexión activa, a grandes rasgos, como la suma de proxy_buffer_size más (N × tamaño del búfer) de proxy_buffers. Con 8 búferes de 16 k más 16 k de encabezado, llegamos a unos 144 KB por solicitud, siempre y cuando todo permanezca en la RAM. Por lo tanto, con 5.000 solicitudes simultáneas, calculo unos 720 MB de ocupación pura del búfer, más la sobrecarga de la Procesos. A medida que aumenta el tráfico, también lo hace la demanda; por eso establezco los márgenes de seguridad de tal forma que se adapten a las respuestas habituales, sin convertir en casos normales las respuestas atípicas con cuerpos de tamaño excesivo. Cuando es necesario, limito las excepciones con Límites de disco, para absorber los picos de demanda de almacenamiento.

Cuándo desactivo deliberadamente el almacenamiento en búfer

Las API en tiempo real, los eventos enviados por el servidor o el vídeo en directo requieren una conexión directa Rendimiento sin almacenamiento en búfer adicional. En esos casos, desactivo proxy_buffering y apuesto por un Transmisión. El proxy transmite los datos de inmediato, lo que evita picos de latencia en los datos en tiempo real, pero mantiene abierta la conexión con el backend durante más tiempo. Para estos patrones, merece la pena echar un vistazo a Flujo de respuesta, incluyendo un ajuste adecuado de los parámetros de keepalive y timeout. Es importante tener en cuenta el mayor consumo de recursos por conexión y establecer los límites correspondientes.

Configurar los «Busy Buffers» de forma selectiva

Con proxy_busy_buffers_size Con ello controlo la cantidad de memoria „lista para el envío“ que permanece bloqueada al mismo tiempo. Si el límite es demasiado bajo, la entrega se ralentiza; si es demasiado alto, aumentan los picos de uso de la RAM. Por lo tanto, elijo un valor que corresponda a entre 1 y 2 veces el tamaño del búfer, para que NGINX envíe los paquetes rápidamente sin consumir demasiada Memoria . En el caso de los clientes lentos, acepto un poco más de «busy-space» para reducir el riesgo de cambios de contexto frecuentes. Las redes rápidas se benefician de valores más bajos, que Memoria necesaria mantenerlo dentro de lo previsible.

Archivos temporales: ruta, tamaño, límites

Activo las Archivos solo cuando los «bodies» son de gran tamaño o la memoria RAM es escasa. Si los archivos temporales se almacenan en un SSD, los tiempos de respuesta siguen siendo aceptables; en un disco más lento, las operaciones de E/S ralentizan rápidamente todo el Cadena de respuestas. Con la opción `proxy_max_temp_file_size` me protejo contra un uso excesivo del espacio; en caso de duda, establezco un límite estricto. Si se producen muchas respuestas grandes en paralelo, preveo espacio suficiente y superviso la carga real. Cuando hay RAM disponible, prefiero utilizar búferes más grandes y mantengo las partes críticas en el Memoria.

Ajuste iterativo, métricas y pruebas

Empiezo con conservador Valores, mide, ajusta y repite el ciclo. Las métricas importantes son la latencia, la tasa de errores, los picos de RAM, los tiempos de espera de E/S y la carga de Trabajador. Las pruebas de carga revelan efectos que pasan desapercibidos en el día a día, como picos en los encabezados debidos a las cookies o respuestas masivas poco frecuentes. Además, ajusto los parámetros de conexión y de los trabajadores de forma conjunta, por ejemplo, Conexiones entre trabajadores y Keepalive. Compruebo cada cambio de forma controlada para poder evaluar el impacto de la Tampón puedo asignarlo claramente.

Almacenamiento en búfer de solicitudes y subidas

Los búferes de respuesta son solo la mitad de la verdad. En el lado de entrada controla proxy_request_buffering, si NGINX almacena en el búfer los cuerpos de los clientes (por ejemplo, las subidas) hasta que estén completos o los transmite directamente al servidor de origen. En el caso de las API que reciben archivos de gran tamaño, suelo desactivar el almacenamiento en búfer de las solicitudes: el servidor de origen recibe el flujo antes, se reducen los tiempos de espera y NGINX no tiene que almacenar temporalmente en disco los cuerpos de gran tamaño. La desventaja es que la conexión con el servidor de origen permanece abierta durante más tiempo y depende en mayor medida de la velocidad del cliente. En el caso de formularios clásicos o solicitudes JSON más pequeñas, mantengo activado el almacenamiento en búfer de solicitudes para suavizar los picos de tráfico y controlar mejor los recursos del servidor. Lo combino con client_max_body_size y una que vaya a juego client_body_buffer_size, para que los valores atípicos se descarten desde el principio o se amortigüen adecuadamente.

Control de Pro-Response: X-Accel-Buffering, Chunked y longitudes

Para un control más preciso, desactivo el almacenamiento en búfer por respuesta a través de X-Accel-Buffering Del código fuente: el encabezado „X-Accel-Buffering: no“ indica a NGINX que transmita la respuesta directamente, incluso si la opción «proxy_buffering» está activada globalmente. Lo utilizo para SSE, long polling o flujos de diagnóstico, sin sacrificar la configuración general. Además, me aseguro de que la configuración sea correcta Longitud del contenido, siempre que sea posible: si NGINX conoce la longitud, planifica los búferes y los archivos temporales de forma más predecible que si se utilizara exclusivamente troceado se transmite. Cuando se desconoce la longitud (por ejemplo, en transmisiones en directo), calculo las necesidades de forma conservadora y aseguro las operaciones de E/S con límites. En el caso de páginas de error o respuestas JSON pequeñas, mantengo el almacenamiento en búfer activado de forma estricta, para que el enlace ascendente quede libre cuanto antes.

Compresión y protocolos: HTTP/2/3 al detalle

La compresión y el almacenamiento en búfer deben considerarse conjuntamente. ¿Es gzip O, si Brotli está activo, la compresión se beneficia de los bloques de datos contiguos en la RAM. Unos búferes demasiado pequeños pueden limitar el rendimiento, ya que el compresor tiene que cambiar de contexto con mayor frecuencia. Por eso elijo tamaños de búfer que agrupen bien los segmentos de respuesta típicos, sin que la RAM se sature en cada conexión. En HTTP/2 y HTTP/3 Con el multiplexado y el control de flujo, la velocidad de envío varía según cada flujo; el almacenamiento en búfer estabiliza el lado del backend, mientras que NGINX sincroniza los flujos de forma precisa. Importante: en rutas muy sensibles a la latencia, reducir ligeramente el „busy space“ puede ayudar a mitigar los efectos «head-of-line»; en conexiones «potentes» con ventanas grandes, asigno un poco más de «busy space» para mantener el máximo rendimiento de envío.

Caché de proxy y solicitudes de rango: interacción con los búferes

Quién proxy_cache Si se utiliza NGINX, el presupuesto para los búferes y los archivos temporales debe estar bien coordinado. NGINX puede almacenar en caché las respuestas y entregarlas a los clientes al mismo tiempo; disponer de suficiente memoria RAM para los búferes acorta la duración de la conexión con el backend, mientras que la coincidencia en la caché desacopla por completo las solicitudes posteriores. Limito los archivos temporales de forma más estricta cuando la caché está «caliente» y los habilito mientras se está acumulando la tasa de aciertos. En Solicitudes de gama (Descargas parciales): decido si las sirvo directamente desde la caché o si primero las dejo cargar por completo en la memoria intermedia. Los rangos frecuentes de archivos grandes se benefician de tamaños de memoria intermedia cuidadosamente equilibrados y de respuestas segmentadas opcionalmente, para que ni las E/S de disco ni la RAM se descontrolen.

Clientes lentos: cómo controlar el rendimiento sin agotar la memoria RAM

La mayor parte de los efectos de almacenamiento en búfer solo se aprecian con clientes muy lentos. Yo utilizo send_timeout y opcionalmente limit_rate/limit_rate_after, para proteger a los destinatarios reticentes sin ocupar en exceso a los trabajadores. Si se aplica una limitación muy estricta, los búferes de «busy» deben aumentar; de lo contrario, se corre el riesgo de que se produzcan bloqueos; al mismo tiempo, controlo el número de conexiones paralelas por IP para mitigar los patrones anómalos. Para descargas con una combinación de clientes (móvil, wifi, fibra óptica), resultan útiles unos valores moderados de «Busy» y unos «Body Buffers» algo más generosos, de modo que NGINX envíe datos de forma lineal mientras el servidor de origen ya está ocupado con la siguiente solicitud.

Operaciones en contenedores y orquestación

Lo planifico en contenedores proxy_temp_path A tener en cuenta: o bien un volumen de host rápido (SSD) o bien un tmpfs, si hay suficiente RAM disponible. Los límites de los contenedores (memoria/CPU/almacenamiento efímero) afectan directamente a los búferes y a los archivos temporales; mantengo un margen suficiente para los picos y regulo el número de trabajadores y conexiones en paralelo en consecuencia. Siguen siendo importantes ulimit -n (descriptores de archivos) y las cuotas del Orchestrator: si la memoria efímera es demasiado pequeña, los archivos temporales generan errores; si la RAM es insuficiente, los trabajadores se bloquean bajo la presión de OOM. Dimensiono los búferes de tal forma que los picos de carga típicos se mantengan estables dentro de los límites del contenedor, y superviso continuamente el espacio real que ocupan los directorios temporales.

Valores iniciales y plantilla para aplicaciones web habituales

Como punto de partida fiable, utilizo un perfil breve que luego perfecciono con los valores de medición. Ejemplo:

location / {
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering on;

    # Búferes de encabezado y cuerpo
    proxy_buffer_size 16k;
    proxy_buffers 16 16k;
    proxy_busy_buffers_size 64k;

    # Archivos temporales solo como medida de seguridad
    proxy_max_temp_file_size 256m;
    proxy_temp_path /var/cache/nginx/proxy_temp 1 2;

    # Tiempos de espera y envío
    proxy_read_timeout 60s;
    send_timeout 30s;

 # Opcional: transmisión de archivos en la subida, según la API
    # proxy_request_buffering off;
}

De este modo, las respuestas de tamaño medio permanecen íntegramente en la RAM, el «upstream» queda libre pronto y los archivos temporales solo se utilizan en caso de valores atípicos. En la segunda ronda, adapto el número de búferes al paralelismo real; si las respuestas son breves y frecuentes, aumente ligeramente el tamaño de «busy» si es necesario, y limito más estrictamente los archivos temporales en cuanto la tasa de aciertos de la caché sea suficiente.

Supervisión y registro: hacer visible el impacto

Mido de forma sistemática: 1TP4Hora_petición y $upstream_tiempo_respuesta en el registro de acceso se puede comprobar si el enlace ascendente se desconecta prematuramente. 1 TP4 Tbytes_enviados y $body_bytes_sent ayudan a ajustar los perfiles de búfer al tráfico real. Si la diferencia entre el tiempo de upstream y la duración total disminuye, los búferes funcionan correctamente. Relaciono esto con los picos de RAM, la espera de E/S y la ocupación del proxy_temp_path. En las pruebas de estrés, varío las velocidades de los clientes, los niveles de respuesta y la carga de los encabezados (por ejemplo, las cookies) para detectar casos extremos. Solo cuando las métricas de los registros y los valores del sistema se mantienen estables dentro de mi rango objetivo, congelo el perfil y documento los límites, así como las vías de escalación (buferajes mayores, otra política de temperatura, réplicas adicionales).

Problemas habituales y cómo solucionarlos

El mensaje „Se ha enviado un encabezado demasiado grande en la dirección de origen“Lo soluciono aumentando el valor de `proxy_buffer_size` y, si es necesario, el de los `proxy_buffers`. Si se producen tiempos de espera en dispositivos lentos, aumento moderadamente los tiempos de espera de envío y dejo un poco de margen a los búferes ocupados. Si se llena el directorio temporal, reduzco el tamaño máximo o aumento los búferes de RAM, en función de la relación coste-beneficio. Si la entrega se ralentiza, compruebo si hay cuellos de botella en la E/S, saturación de la CPU y la distribución de los Tampón. Cuando se producen situaciones de escasez, siempre las abordo primero basándome en datos medidos, no con duplicaciones generales.

Conclusión: mis puntos clave sobre el almacenamiento en caché del proxy de NGINX

En primer lugar, defino los típicos Tamaños de respuesta, la carga máxima y los perfiles de cliente, antes incluso de ajustar los búferes. A continuación, configuro un búfer de encabezado lo suficientemente grande como para evitar errores innecesarios. Dimensiono los búferes de cuerpo de tal manera que las respuestas habituales permanezcan en la RAM y solo las excepciones se almacenen en Disco caen. Configuro los «Busy Buffers» de tal forma que las transferencias se realicen con fluidez, sin malgastar memoria. Por último, lo compruebo todo con pruebas de carga y supervisión hasta que la latencia, el rendimiento y los requisitos de memoria se sitúen en un nivel fiable Windows mentira.