Optimizar un servidor Nginx 2/2

Optimizar un servidor Nginx.

El siguiente articulo es la continuación de este anterior, seguimos con la optimización de un servidor Nginx.

Tal vez te interese leer este articulo donde se explica su instalación como proxy inverso, este otro donde se brindan unos consejos de seguridad en Nginx.

En esta segunda y ultima parte veremos como configurar las caches correctamente en un servidor Nginx.

 

Cache del cliente

La manera más sencilla de reducir las peticiones de un servidor Nginx, es que los clientes crean que el contenido esta actualizado

Estableceremos encabezados que admitan caché, para ello declararemos que todas las imágenes, etc…, están con un limite de tiempo.

Optimizar un servidor Nginx 2/2 1

 

Como ejemplo y a 30 días:

location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
         access_log        off;
         log_not_found     off;
         expires           30d;
     }

Como ves, hemos desactivado el registro de archivos multimedia y configurado varios sufijos que se considerarán válidos (por tanto no se solicitaran) durante 30 días.

 

Cache Filehandle

Si estás sirviendo una gran cantidad de archivos estáticos, es una buena idea el mantener abierto el controlador de archivos a archivos solicitados, de forma que evitaremos que este abriendo y cerrando constantemente.

Solo debes habilitarlo si no estas editando ningún archivo. Los accesos a los archivos están en la memoria caché, los errores 404 también se almacenarán en la caché, de la misma forma que los que cuentan los tamaños de archivos, por tanto si modificas un archivo el servidor respondera con archivos obsoletos o inexistentes.

Puedes usar este ejemplo, en el archivo de configuración de Nginx, o incluso en el propio encabezado del HTTP:

open_file_cache          max=2000 inactive=20s;
open_file_cache_valid    60s;
open_file_cache_min_uses 5;
open_file_cache_errors   off;

Este codigo le dice al servidor que guarde en caché 2000 controladores de archivos abiertos, cerrando los  controladores que no tienen hits en 20 segundos. Los identificadores en caché se consideran válidos durante 60 segundos y solo los archivos a los que se accedió cinco veces se considerarán adecuados para el almacenamiento en caché.

El resultado es que los archivos a los que se accede con más frecuencia tienen identificadores almacenados en caché, lo que reducirá los accesos al sistema de archivos.

Optimizar un servidor Nginx 2/2 2

 

Tunear PHP en un servidor Nginx

Este apartado es importante, sobre todo si usas cms del estilo WordPress.

Como Nginx no tiene un mod_php,de forma nativa, la forma recomendada de ejecutar aplicaciones PHP implica el uso de PHP-FPM . Para usar PHP-FPM, las peticiones de proxy para los archivos PHP, son las siguientes:

# execute all .php files via php-fpm
        location ~ .php$ {
            # connect to a unix domain-socket:
            fastcgi_pass   unix:/var/run/php5-fpm.sock;
            fastcgi_index  index.php;

            fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
            fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;

            fastcgi_buffer_size 128k;
            fastcgi_buffers 256 16k;
            fastcgi_busy_buffers_size 256k;
            fastcgi_temp_file_write_size 256k;

            # This file is present on Debian systems..
            include fastcgi_params;
        }

Este código usara un socket de unix, por tanto debes asegurarte de modificar…
# en caso de php 5.x, si usas el 7 será lo mismo pero cambiando la versión.

/etc/php5/fpm/pool.d/www.conf

listen = /var/run/php5-fpm.sock

de esta forma escuchara el socket del dominio, no de la red.

 

PHP-FPM, por defecto inicia excesivos procesos hijos, te recomiendo que los bajes:

nano /etc/php5/fpm/pool.d/www.conf

; set a fixed number of php workers
pm = static

; start up 12 php processes
pm.max_children = 12

Optimizar un servidor Nginx 2/2 3

 

El valor 12 es un ejemplo, prueba tu servidor con carga para ver cuando obtienes mejor rendimiento.

Deberías configurar PHP-FPM para que reinicie automáticamente, si hay algún problema.

En el ejemplo, reiniciaremos PHP-FPM en caso de que diez procesos secundarios mueran en un 1 minuto, también dejaremos pasar 10 segundos antes del reinicio.

nano /etc/php5/fpm/php-fpm.conf

agregamos…
emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s

 

Como ultimo apunte… usa el Zend Opcache, mejorara el rendimiento incluso al montar PHP-FPM.

Agregar comentario