Ahora que Nginx está en boca de muchos devs gracias a la compra de este por parte de la compañía F5 (que muchos no sabíamos que existía si quiera😛), me puse a pensar, ¿por qué no hacer una publicación de Nginx?, así que aquí está.

Cabe destacar que esta publicación toma en cuenta de que ya conoces Nginx y tienes una idea de este, por lo que si no tienes conocimiento todavía de este, te recomiendo empezar desde ya porque Nginx es el mejor servidor web/proxy inverso que hay (oops, Apache, lo siento…pero sabes que es verdad).

1.- Recursos en cache

Cada sitio web maneja lo que llamamos contenido estático, es decir, contenido que no cambia a menos que se haga su cambio manual, como una imagen, un archivo JS que hace que el slider funcione, el CSS de ese widget molesto que sale para decirnos que si queremos suscribirnos al boletín, etc…

Es por ello que, al cachear estos recursos en el navegador, al volver a visitar el sitio, ya no manda pedirlos si no que los carga del recurso local haciendo que el sitio en cuestión sea más rápido la segunda vez que lo visitamos (o que nos visitan) y ahorra recursos tanto al servidor, como al visitante (¿a quién le gusta visitar esos sitios que pesan como 50 megas y gastarse sus datos porque un amigo nos dijo que vieramos ese GIF gracioso?)

Para todo esto, usamos la siguiente configuración:

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {expires 365d;}

Al hacer esto, cualquier archivo con las extensiones mencionadas (jpg —-js) quedarán almacenadas en el cache si permanecen intactas por 365 días. Se puede hacer una configuración específica para que por ejemplo sabiendo que las imágenes es aún más raro que cambien, se mantengan con esta pero los CSS que sí pueden cambiar y a veces el cache no se quiere vaciar y nos toca forzarlo con “?v=x.x.x”, se seteen en 7 días o cuestiones un poco más bajas.

2.- Ajusta los procesos del Worker

Los servidores son multi-hilos y multi-procesos hoy en día, por lo que pueden ejecutar distintas tareas en distintos hilos para terminarlas más rápido, y Nginx aprovecha esto para ser más rápido, sin embargo las configuraciones predefinidas en Nginx nos limitan a utilizar lo más simple posible ya que para Nginx nuestro sitio es algo “bastante sencillo”, pero como aquí buscamos rendimiento se requieren de cambiar.

¿Cómo se cambian entonces estas configuraciones?. Bueno, para ello está worker_processes que es el parámetro que hará uso de los múltiples procesadores disponibles en tu sistema. Si tienes 4, este valor puede ser 4, si tienes 8 puedes poner el valor en 8 quedando entonces:

worker_processes 8;

Como dato: Un “worker” se puede “traducir” como un trabajador que responde a un jefe, ya que Nginx tiene un “proceso maestro” y estos “workers” son como sus empleados. No es por ser políticamente incorrectos, simplemente así se hace la referencia.

3.- Incrementa las conexiones del Worker

Las conexiones del Worker están relacionadas a sus procesos, por ejemplo, si marcamos 4 conexiones y tenemos 4 workers, podremos tener 16 conexiones porque son 4 conexiones por cada Worker.

Aquí deberás tener en cuenta el valor dependiendo del tráfico que manejes pero sin excederte, porque si lo haces, las conexiones serán encoladas y podrían resultar en un timeout, así que deberás tener en mente este aspecto. No quiero entrar en detalle aquí en cómo podemos manejar basado en fórmulas así que normalmente se recomienda un valor de 1024 y al tener por ejemplo 4 worker_processess son 4,096 conexiones simultáneas, lo cual para un sitio de tráfico medio es bastante bueno.

Quedando entonces:

events { worker_connections 1024; }

4.- Optimización para valores de Timeout

El “timeout” se da cuando una petición/visita no logra concretarse en cierto tiempo, a veces los timeouts son tan elevados que un visitante a nuestro sitio, o API o lo que sea que tengamos, se queda “las horas” esperando porque que se van encolando las peticiones hasta que logran terminar en timeout por que nuestro servidor se saturó, están tratando de pedir muchos datos o cualquier otro motivo y todo esto pues apoya más a la saturación del servidor.

Es por ello que la mejor configuración es tomar en cuenta el promedio de tiempo de respuesta y agregarle un 25% a esa respuesta. Por ejemplo, pensemos que por alguna razón nuestro endpoint en un API tarda en responder un aproximado de 10 segundos, sabemos que nuestros picos máximos son de 11 segundos, nuestros mínimos de 9 y el promedio queda en 10, por poner un ejemplo, entonces nuestro mejor timeout sería de 12 segundos. De esta forma si se encolan peticiones podrán liberarse rápido y volver a recibir más.

Es por ello que entonces usamos las siguientes configuraciones:

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 12;

No profundizaré en este apartado pero así es más o menos…

5.- Compresión

Todos hemos usado Winrar, o 7zip, o cualquier servicio de compresión en el que un archivo se hace más pequeño, bueno gracias a Nginx podemos hacer algo parecido con Gzip.

Lo mejor cabe destacar es que aunque podemos ahorrarnos unos cuantos bytes en la tranferencia es no activarlo para todos los archivos ya que utiliza CPU y pues podemos saturar el servidor, suerte que el cache nos ayuda.

Con esto en mente entonces, una configuración básica podría ser:

gzip on;
gzip_vary on;
gzip_min_length 512;
gzip_comp_level 6;
gzip_proxied any;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;
gzip_buffers 16 8k;
gzip_disable "MSIE [1-6].(?!.*SV1)";

6.- Buffers

Los “Buffers” son básicamente un método para temporalmente almacenar la respuesta a cada cliente de forma individual y así, permitir la conexión al servidor que está en el proxy para cerrar antes.

Suena un poco confuso, y es un poco más complicado de explicar, así que por ahora te dejaré que investigues por tu cuenta y dejaremos las configuraciones como las siguientes a nivel básico:

client_body_buffer_size 128k;
client_max_body_size 10m;
client_header_buffer_size 1k;

7.- Desactivar los registros de acceso

Esto es fácil de explicar, cada vez que alguien visita nuestro sitio Nginx guarda un registro de su petición, por lo que en algún momento los archivos se hacen de gigas y le cuesta más trabajo a Nginx cada vez abrir estos archivos y escribir en ellos…¿cuál es la mejor opción?, quitarlos.

Cabe destacar que, quitar estos registros no retira los registros de error, esos siguen activos, por lo que con la siguiente configuración se deshabilita:

access_log off;

8.- TCP…

Esta configuración en pocas palabras y para no irnos tan allá, nos permite prevenir que nuestro sistema se ponga a almacenar gran cantidad de información y en vez de ello se pone a enviar en pequeñas ráfagas de información en tiempo real. El tcp_nopush permite enviar todo en un paquete en vez de en pequeñas partes.

Para ello usamos la siguiente configuración:

tcp_nodelay on;
tcp_nopush on;

9.- open_file cache

Estas dos secciones refieren a Linux específicamente, en esta primer sección este parámetro permite que, ya que Linux utiliza casi todo (si no es que todo) con archivos, mantener en caches los archivos para evitar que tengan que ser re-leídos. Simplemente basta con agregar la siguiente configuración:

open_file_cache max=5000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

10.- El último y nos vamos… Cola de conexión

Esta configuración realmente no refiere directamente a Nginx, y les recomiendo que no lo hagan si no tienen idea real de cómo configurar esta parte, ya que, puede ser dañino para su sistema operativo.

Como mencioné en el punto 9, este punto también va con Linux y es que refiere a la longitud de las conexiones que necesitan ser aceptadas por Nginx. Estas configuraciones las encuentras en /etc/sysctl.conf y realmente te recomiendo investigar antes correctamente acerca de ellas ya que esto es algo así como una fórmula y no hay dato exacto pero si le mueves aquí puede que algo falle así que ten cuidado te dejo una demostración de las configuraciones:

net.core.somaxconn = 65536
net.ipv4.tcp_max_tw_buckets = 1440000

Conclusión

La mayoría de configuraciones aquí son para que juegues con ellas y adaptes las mejores a tu sitio, recuerda, no por tener altos los valores significa que es mejor, debes encontrar el balance perfecto entre ellas.