que - servicio php fpm para apache

Optimice 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 para 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

Solo incluí los parámetros de PHP-FPM que cambié para PHP-FPM.

¿Alguien tiene algún consejo sobre cómo puedo optimizarlo para poder 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 comenzar con 2 - 4 trabajadores nginx es suficiente ...

Answer 2

Definitivamente debería reducir el número de trabajadores ya que dudo que tenga 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í.

Además, ha aumentado el worker_rlimit_nofile a 50000 , espero que sepa que el sistema operativo generalmente establece el límite en 1024 (valor predeterminado), puede intentar solicitar cuál es el límite actual escribiendo ulimit -n

Puede aumentar el límite estricto de NOFILE (número de archivos abiertos) ejecutando este comando ulimit -n 50000 en init.d o visite esta otra pregunta en para aprender a usar limits.conf para establecer permanentemente límites en todo el sistema.

Answer 3

Definitivamente también es posible que trabajadores como la gente lo hayan mencionado. Yo personalmente prefiero xcache sobre APC para el caché de código de operación php. Debería verificar la configuración en el script de instalación de Centmin auto bash shell nginx / php-fpm modificado http://vbtechsupport.com/796/

Answer 4

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. Recuento de trabajadores: 20 tiene poco sentido si no tiene una máquina de 20 procesadores / núcleo, en realidad está causando un efecto negativo ya que los trabajadores tendrán un intercambio de contenido excesivo. Si está ejecutando un procesador de doble núcleo, 2 trabajadores deberían ser suficientes.

2. Conexiones con los trabajadores: Nuevamente, 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 raíz y la configuración de PHP se refieren a http://wiki.nginx.org/Pitfalls , funciona mejor si coloca su directiva raíz en el nivel del servidor {}, no en el nivel de ubicación. Una vez que lo haga, puede usar $ document_root $ fastcgi_script_name como el valor 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. Utilice un acelerador de PHP, es decir, APC (con apc.enabled = 1 en php.ini) o XCache, y tenga en cuenta su configuración de php, como 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 5

La forma más efectiva de hacer que un sistema de servidor sea mucho más rápido es usar FacebookHipHop 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 normalmente el código PHP de 5 a 10 veces más rápido que PHP, lo que hace posible llevarse bien con un menor número de servidores o servidores más pequeños y reducir el consumo de energía. esencialmente. Wikipedia usó HHVM para reducir la carga del servidor de la 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 Linux y se puede incluir en Nginx de forma muy sencilla, similar a FastCGI, y poco después se puede probar a través de un pequeño archivo PHP "Hello World": https://github.com/facebook/hhvm/wiki/Getting-Started

El nuevo PHPNG de PHP7 debería ser verdad según las pruebas de referencia solo un 30% más rápido.

gracias por votacion

Answer 6

Realmente impulsar el rendimiento al máximo 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.

Coloque sus pancartas en una montura tmpfs, no inicie sesión en access_log o error_log, deshabilite los módulos que no necesita en php, use una versión reciente de mysql, use innodb para reducir el bloqueo de la tabla, juegue con el método de descarga de innodb para reducir el disco escribe, aumenta las tablas de memoria máximas en mysql para reducir la creación de archivos temporales en el disco cuando se solicitan las uniones a través de 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, contratar a un profesional :-)

Answer 7

También sería útil poner:

access_log off;

Como supongo que realmente no te importa la generación de registros en estas solicitudes.