Optimizar Nginx + PHP-FPM para tiempos de respuesta más rápidos (para el servicio de anuncios de Openx)

Question

Actualmente estoy ejecutando Nginx + PHP-FPM para publicar anuncios en OpenX. Actualmente mis tiempos de respuesta son horribles, incluso en momentos de poca carga. Sin embargo, mis recursos de CPU y memoria están bien, así que no puedo entender cuál es el cuello de botella.

Mi configuración actual de Nginx y php-FPM es:

worker_processes 20; 
worker_rlimit_nofile 50000; 

error_log /var/log/nginx/error.log; 
pid  /var/run/nginx.pid; 

events { 
    worker_connections 15000; 
    multi_accept off; 
    use epoll; 
} 

http { 
    include  /etc/nginx/mime.types; 

    access_log /var/log/nginx/access.log; 

    sendfile  on; 
    tcp_nopush  off; 

    keepalive_timeout 0; 
    #keepalive_timeout 65; 
    tcp_nodelay  on; 

    gzip on; 
    gzip_disable "MSIE [1-6]\.(?!.*SV1)"; 
    gzip_comp_level 2; 
    gzip_proxied any; 
    gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; 

    include /etc/nginx/conf.d/*.conf; 
    include /etc/nginx/sites-enabled/*; 
} 

server { 
    listen 80; 
    server_name localhost; 
    access_log /var/log/nginx/localhost.access.log; 

# Default location 
    location/{ 
     root /var/www; 
     index index.php; 
    } 

## Parse all .php file in the /var/www directory 
    location ~ .php$ { 
     fastcgi_pass localhost:9000; 
     fastcgi_index index.php; 
     fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name; 
     include fastcgi_params; 
     fastcgi_param QUERY_STRING  $query_string; 
     fastcgi_param REQUEST_METHOD $request_method; 
     fastcgi_param CONTENT_TYPE  $content_type; 
     fastcgi_param CONTENT_LENGTH $content_length; 
     fastcgi_ignore_client_abort  off; 
    } 

PHP-FPM: 
rlimit_files = 50000 
max_children = 500 

que sólo se incluyeron los parametros de PHP-FPM he cambiado para PHP-FPM.

¿Alguien tiene alguna sugerencia sobre cómo puedo optimizarlo para que pueda atender más solicitudes? Estoy viendo tiempos de respuesta horrendos en este momento.

Answer 1

¿tiene 20 procesadores o núcleos en su máquina? también puede intentar eventos con el valor predeterminado para su sistema operativo ... tal vez más procesos fcgi en lugar de más nginx ... probablemente comenzando con 2 - 4 trabajadores nginx es suficiente ...

Answer 2

Definitivamente debe reducir el número de trabajadores como Dudo que tengas 20 núcleos/procesadores. Además, examinaría el servidor de su base de datos, hay una gran posibilidad de que el problema esté allí.

Adicionalmente usted ha subido la worker_rlimit_nofile a 50000, espero que sepas que el sistema operativo normalmente se establece el límite a 1024 (por defecto), se puede tratar de pedir lo que es el límite actual escribiendo ulimit -n

Puede aumentar límite estricto de NOFILE (número de archivos abiertos) mediante la ejecución de este comando ulimit -n 50000 en init.d o visit this other question on stackoverflow para aprender a usar limits.conf para establecer permanentemente los límites de todo el sistema.

Answer 3

En primer lugar, demasiados trabajadores, y los límites establecidos excesivamente altos. El recuento máximo de trabajadores para php-fpm solo haría que tu servidor cayera un poco. Desconectar los límites en un servidor no necesariamente lo acelerará, pero en realidad puede tener el efecto opuesto.

1. Trabajador Contador de visitas: 20 no tiene mucho sentido si no tiene una máquina/núcleo 20 de procesador, en realidad está causando un efecto negativo ya que los trabajadores tendrán intercambio de contenido excesivo. Si está ejecutando un procesador de doble núcleo, 2 trabajadores deberían ser suficientes.

2. Conexiones de los trabajadores: De nuevo, solo tirar un límite a los cielos no resuelve tus problemas. Si su salida de ulimit -n es algo así como 1024, entonces las conexiones de su trabajador deberían establecerse en 1024 o menos (tal vez incluso 768), es poco probable que tenga 2 x 1024 conexiones simultáneas especialmente con algo como PHP.

3. La ubicación de la raíz y la configuración de PHP se refieren a http://wiki.nginx.org/Pitfalls, funciona mejor si coloca su directiva de raíz en el nivel del servidor {}, no en el nivel de ubicación. Una vez hecho esto, puede usar $ document_root $ fastcgi_script_name como el valor de SCRIPT_FILENAME, ya que $ document_root se propagará automáticamente a los bloques de ubicación debajo de él.

4. Es posible que desee manejar archivos estáticos directamente, en otras palabras:

   location ~* \.(ico|css|js|gif|jpe?g|png)$ { 
       expires max; 
       add_header Pragma public; 
       add_header Cache-Control "public, must-revalidate, proxy-revalidate"; 
   } 
   

5. uso de un acelerador de PHP, es decir APC (con apc.enabled = 1 en php.ini) o XCache, y estar teniendo en cuenta su configuración de php, como el memory_limit.Por ejemplo, si solo tiene un sistema con 2 GB de RAM, tiene muy poco sentido permitir 500 trabajadores con un límite de 128 MB cada uno. Especialmente cierto si también está ejecutando otros servicios en su servidor.

Answer 4

Definitivamente también es posible que trabajadores como la gente ha mencionado. Personalmente prefiero xcache sobre APC para el caché de código de operación php. Que debe salir de configuración automática con cáscara centmin fiesta modificado nginx/php-FPM script de instalación http://vbtechsupport.com/796/

Answer 5

Sería también útil para poner:

access_log off; 

como supongo que realmente no se preocupan de generación de registros de estas solicitudes.

Answer 6

Realzar al máximo el rendimiento con nginx y php5-fpm es un arte. Se necesita comprender realmente el tipo de contenido que está sirviendo.

Por ejemplo, no veo ningún uso de try_files ni ningún tipo de almacenamiento en caché en su configuración. ¿Sabes que nginx viene con soporte de memcache incorporado? Puede almacenar en caché imágenes y html/css, así como también páginas de php. Si le importan principalmente los clics, esos clics seguirán contando, incluso si las pantallas no lo son.

Ponga sus banderas en un montaje tmpfs, no inicie sesión access_log o error_log, desactivar los módulos que no es necesario en php, utilice una versión reciente de MySQL, utilice innodb para reducir bloqueo de tablas, juega con el método de lavado innodb para reducir las escrituras en disco, aumentar las tablas de memoria máximas en mysql para reducir la creación de archivos temporales en el disco cuando se solicitan las uniones mediante SQL, etc.

Nginx es solo una parte de una fórmula muy grande y compleja. Ni siquiera he mencionado Kernel params para optimizar el rendimiento de TCP Stack y tarjeta de red, uso de intercambio, uso de memoria o compresión gzip de HTML/CSS que puede estar sirviendo a través de OpenX (si lo es).

Y sí, al igual que otros mencionados anteriormente, su configuración parece excesiva y muestra una falta de comprensión de los conceptos básicos de optimización. En otras palabras, contrate a un profesional :-)

Answer 7

La manera más efectiva de hacer que un sistema de servidor sea mucho más rápido es usar Facebook HipHop Virtual Machine (HHVM) en lugar de PHP (PHP no debe instalarse más).

HHVM utiliza un Compilador Just in Time upstream de la CPU y ejecuta el código PHP de 5 a 10 veces más rápido que PHP, permite trabajar con un menor número de servidores o servidores más pequeños y reducir el consumo de energía esencialmente. Wikipedia utiliza HHVM para reducir la carga del servidor CPU por el factor 5: http://www.golem.de/news/php-facebooks-hhvm-macht-wikipedia-schneller-1501-111515.html

Se puede instalar junto con Nginx como paquete de Linux y se incluirá en Nginx muy fácilmente similar a FastCGI, y pronto después de unos minutos puede ser probado a través de un pequeño archivo PHP "Hello World": https://github.com/facebook/hhvm/wiki/Getting-Started

El nuevo PHPNG PHP7 debe ser cierto según las pruebas comparativas solo un 30% más rápido.

gracias por votar