Se tratan las principales configuraciones para optimizar el rendimiento del servidor web nginx, incluyendo la compresión gzip, la configuración de proxy_buffer, y la configuración de los procesos worker y keep-alive.
Se destaca la importancia de la compresión gzip y el almacenamiento en búfer proxy_buffer para reducir la cantidad de datos transferidos y minimizar la carga del servidor, así como la gestión de conexiones mediante la configuración de los procesos worker y keep-alive.
Se presentan las precauciones para la operación estable del servidor, aplicando la configuración óptima para el entorno del servidor después de varias pruebas.
Nginx es un servidor web o servidor proxy web de código abierto ampliamente utilizado.
Con una configuración adecuada, puede entregar contenido estático de manera eficiente.
En este artículo, documentaré algunas de las configuraciones clave.
Algunas configuraciones clave relacionadas con el rendimiento
1. Compresión gzip
Al cargar un sitio web, se reciben numerosos archivos como JavaScript, imágenes, HTML y CSS del servidor web.
En lugar de enviar este contenido en su forma original, el uso de la compresión gzip puede reducir significativamente la cantidad de datos transmitidos.
Es decir, al aplicarlo:
- Se reduce la cantidad de datos, lo que ahorra ancho de banda.
- Se pueden ahorrar recursos del servidor.
- Desde la perspectiva del usuario, la velocidad de carga real aumenta.
Por otro lado, dado que el servidor debe realizar la compresión gzip antes de responder al contenido, el uso de la CPU del servidor puede aumentar.
Es necesario realizar pruebas antes de la implementación en el entorno de producción para determinar qué tipos de archivos comprimir, el nivel de compresión y el tamaño de los archivos a comprimir.
A continuación, se muestran algunas configuraciones relacionadas con gzip.
gzip on; # Habilita la compresión gzip.
gzip_vary on; # Agrega Vary: Accept-Encoding al encabezado.
gzip_proxied any; # Si se utiliza nginx como servidor proxy, comprime la respuesta recibida del backend (compresión para solicitudes proxificadas).
gzip_min_length 256; # Comprime solo archivos de 256 bytes o más.
gzip_comp_level 5; # Establece el nivel de compresión de 1 a 9. Cuanto más alto, mayor el uso de la CPU. 5 comprime aproximadamente el 50%.
gzip_types text/plain text/css text/xml application/json application/javascript;
// Establece los tipos de contenido a comprimir.
* gzip_vary indica que el contenido puede enviarse en versiones comprimidas y sin comprimir según si el cliente admite gzip o no. (Indica que se puede proporcionar una versión diferente del contenido según el encabezado de solicitud del cliente (Accept-Encoding)).
2. Configuración de proxy_buffer
Nginx almacena la respuesta en un búfer antes de enviarla al cliente.
Cuando el servidor web envía una respuesta al cliente, si la velocidad del cliente es lenta, el servidor debe esperar continuamente para transmitir los datos. (Congestión de la red)
En este caso, dado que los recursos del servidor se están utilizando continuamente, se utiliza un búfer para manejar temporalmente la respuesta independientemente de la velocidad de procesamiento del cliente. Esto proporciona las siguientes ventajas:
- Optimización de la carga del servidor
- Reducción de la congestión de la red
location / {
proxy_pass url_del_servidor;
# Configuración del búfer proxy
proxy_buffering on; # Habilita el búfer.proxy_buffer_size 4k; # Establece el tamaño del búfer.(Principalmente contiene encabezados).proxy_buffers8 4k; # Número y tamaño de búferes para cada conexión(8 de 4 kb).proxy_busy_buffers_size 8k; # Tamaño máximo de búfer disponible mientras se envía la respuesta al cliente.}
※ Si el tamaño del búfer es demasiado grande, la transmisión de datos en tiempo real, como la transmisión de texto, puede retrasarse, por lo que es necesaria una prueba. En particular, dado que recientemente han aparecido muchos servicios relacionados con la IA, si la transmisión de texto no funciona, verifique esta configuración.
3. Configuración de worker y http
Un worker es un proceso que maneja las solicitudes del cliente, y se puede configurar cuántos workers tener por cada núcleo de CPU del servidor.
Http normalmente es solicitud-conexión-respuesta-cierre de conexión, pero para reducir los recursos utilizados para conectar múltiples solicitudes, se puede mantener la conexión del cliente. Esta es la configuración keep-alive.
worker_processes auto; # Configuración automática según la cantidad de núcleos de CPU disponibles.
worker_connections 1024; # Número de conexiones que cada worker puede manejar simultáneamente.
# Configuración keep-alive
keepalive_timeout 65;
keepalive_requests 100;
server {
listen 80;
location / {
proxy_pass url_del_servidor;
}
}
La razón por la que se agrupan estas dos configuraciones es la siguiente:
Si el servidor tiene 4 núcleos, el número teórico de conexiones posibles es 1024 * 4 = 4096.
(Puede no ser preciso según los recursos o el entorno de tráfico)
Cuando 4096 clientes se conectan simultáneamente y ocupan todos los keep-alive durante 65 segundos,
Si un usuario número 4097 intenta conectarse, no podrá hacerlo, lo que puede provocar un retraso en la respuesta.
Por lo tanto, asumiendo que los recursos del servidor son estables debido a la escalabilidad automática, etc., si se produce un retraso en la respuesta durante un evento, la configuración anterior puede tener un impacto indirecto.
4. Otros - bloque location
Algunas configuraciones, como el búfer proxy, se pueden aplicar a cada URL de solicitud.
* Algunas configuraciones, como keep-alive, se aplican a nivel de servidor HTTP y no se pueden configurar por bloque.
server { listen 80; server_name example.com;
# Manejo de la ruta base(/)location/{ proxy_pass url_del_servidor; # Configuración de búfer
proxy_buffering on; proxy_buffers 8 16k; proxy_buffer_size 32k; proxy_busy_buffers_size 64k;}# Manejo de la ruta /test
location/test { proxy_pass url_del_servidor2; # Desactivación del búfer
proxy_buffering off; # Desactiva el búfer(envía la respuesta inmediatamente)}}
Con esta configuración, puede optimizar el rendimiento web. ¡Después de realizar suficientes pruebas considerando varios casos de prueba, optimice el rendimiento del servidor!
* Dado que la configuración modificada de nginx se puede aplicar sin tiempo de inactividad del servidor, en su mayoría es estable.