PHP + Apache time de espera largo

Me he encontrado con un poco de una panetworking de ladrillo con la solución de problemas de mi websever dedicado. Recientemente, mi website clavó con la cantidad de request / por segundo y se estrelló.

La caja original tenía 8GB de RAM, 8 Core Xeon E3-1230, 1TB 7.200 RPM Disco (No Raid), 100Mbit de networkinges dedicadas.

Después de la punta, he aumentado la RAM a 24 GB con el fin de apoyar a más usuarios simultáneos.

Apache parece manejar bien, incluso con 3000 usuarios simultáneos, devolverá HTML y contenido estático muy rápidamente (un-cached).

Para probar aún más las diferencias entre Apache / HTML y Apache / PHP, corrí ab .

Tanto test.html como test.php tienen exactamente el mismo contenido estático, el PHP no llama a ningún include sy no se conecta con MySQL.

Prueba HTML

ab -n 500 -c 50 http://www.~~.com/test.html

 Connection Times (ms) min mean[+/-sd] median max Connect: 252 375 190.3 276 1399 Processing: 254 354 121.5 282 657 Waiting: 253 353 121.4 280 653 Total: 510 730 231.7 573 1675 

Prueba de PHP

ab -n 500 -c 50 http://www.~~~.com/test.php

 Connect: 248 275 51.1 267 1316 Processing: 256 4167 6210.2 2262 41489 Waiting: 253 4166 6210.2 2262 41489 Total: 509 4442 6212.4 2523 41754 

Pingdom también informa de un largo time de espera al acceder a un script PHP. introduzca la descripción de la imagen aquí

Estoy obteniendo un resultado similar en WebPageTest.org, aunque mejor, la primera vez que el byte es F :

  Load Time **First Byte** Start Render DOM Elements Time Requests Bytes In Time Requests Bytes In First View 2.061s **0.839s** 0.000s 55 2.061s 20 428 KB 2.061s 20 430 KB 

Aquí están mis top resultados: introduzca la descripción de la imagen aquí

Prueba de E / S

Bajo carga pesada, el wa% puede boost hasta 95% durante unos pocos milisegundos.

Corrí iostat durante la carga:

 avg-cpu: %user %nice %system %iowait %steal %idle 8.37 0.00 5.18 0.56 0.00 85.88 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 45.50 3.00 48.00 136.00 748.00 17.33 3.05 59.76 2.53 12.90 sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb3 0.00 45.50 3.00 48.00 136.00 748.00 17.33 3.05 59.76 2.53 12.90 avg-cpu: %user %nice %system %iowait %steal %idle 4.00 0.00 3.56 0.69 0.00 91.75 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 6.00 118.50 9.50 21.00 996.00 1116.00 69.25 0.29 9.44 1.66 5.05 sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb3 6.00 118.50 9.50 21.00 996.00 1116.00 69.25 0.29 9.44 1.66 5.05 

Para mí, eso no se ve mal, pero puede que me falte algo.

Estoy usando FCGI

 <IfModule mod_fcgid.c> FcgidMaxRequestLen 1547483648 FcgidMaxRequestInMem 52485760 FcgidIdleScanInterval 15000 FcgidBusyTimeout 15000 FcgidProcessLifeTime 7200 FcgidConnectTimeout 1800 FcgidIOTimeout 1800 PHP_Fix_Pathinfo_Enable 1 FcgidMaxRequestsPerProcess 1000 </IfModule> 

Y aquí está mi Apache Conf (estoy usando 2.4.x)

 Timeout 60 TraceEnable Off ServerSignature Off ServerTokens ProductOnly FileETag None StartServers 10 <IfModule prefork.c> MinSpareServers 5 MaxSpareServers 15 </IfModule> <IfModule itk.c> MinSpareServers 5 MaxSpareServers 15 </IfModule> ServerLimit 2200 MaxRequestWorkers 2000 MaxConnectionsPerChild 15000 KeepAlive On KeepAliveTimeout 1 MaxKeepAliveRequests 2000 

He examinado mis loggings de errores de Apache y los loggings de acceso. Nada extraño para informar.

Estoy realmente rascando mi cabeza aquí.

He intentado apagar el firewall.

He intentado boost Max Connections.

He optimizado mySQL y eliminando muchas consultas lentas (que eran> 0.5s).

¿Qué más puedo hacer, hay algo que pueda usar para ayudar a identificar problemas? Cualquier ayuda sería muy apreciada.

PD:

Vale la pena señalar que, incluso cuando el server está siendo muy visitado, PHPMyAdmin y cPanel siguen siendo muy sensibles. Nada más parece retrasarse excepto el PHP en el website.

Creo que su problema es simplemente su disco duro con sus times de acceso. Apache puede almacenar en cache páginas html en memory, pero los php-scripts no se almacenan en caching; la necesidad de ser ejecutado cada vez otra vez. Por lo tanto, el intérprete php se llama y lee el script desde el hdd. Esto toma mucho time. La cosa más lenta en su server es su HDD. En mi PC, hay una diferencia extrema entre las aplicaciones que empiezan desde mi SSD y mi HDD (el SSD es hasta 10 veces más rápido!). Si su disco duro funciona, entonces la latencia para ejecutar un script php puede boost drásticamente.

Posibles soluciones: obtenga un SSD (quizás uno pequeño sólo para datos a los que se accede con frecuencia, como scripts) y minimice las llamadas de guión (y los accesos a HDD) en su server. Asegúrese de que el sistema de files está desfragmentado (normalmente se hace automáticamente). Si su php-script crea a menudo el mismo contenido, intente almacenarlos en caching en un file html.

Esta respuesta también podría ayudarte a: https://stackoverflow.com/questions/4181865/apache-php-caching

El file HTML que estás probando es sólo un file sencillo, todo lo que Apache tiene que hacer es hacer unas pocas llamadas al sistema (abrir, leer) y luego servir su contenido.

PHP OTOH es realmente una opción "pesada": es un intérprete integer (comstackdor de bytecode?). Y ya que está utilizando las testings simultáneas (-c) ¿quién sabe qué tan bien las requestes se multiplexan a ella? Esto no tiene que ser apache problema en absoluto, sino más bien el problema de PHP.

Lo que haría:

  1. Cambie a Apache MPM (multihilo en múltiples processs).

  2. Haga la testing secuencial (no múltiples peticiones concurrentes), compare.

  3. Ejecute valgrind o algo así en el process de apache y vea donde se gasta el time de la CPU (apache o PHP).

  4. ejecutar la misma testing, pero el service de esta página a través de nginx. Desde nginx se basa en el model asíncrono y muy rápido, entonces si obtiene resultados similares, PHP es el culpable.

  5. Por último, podría instalar Zend Optimizer (testing de 30 días es gratis) o smth como esto: https://github.com/zendtech/ZendOptimizerPlus .

Realmente, la comparación de servir un file estático a la página web generada dinámicamente es una especie de comparación entre manzanas y naranjas. Ninguna de las soluciones típicas (Python mod-apache, Django, PHP, etc) va a ser muy rápido en este sentido, al less en comparación con el service de un file estático. Node.js es quizás una exception, debido a una especie de página web de progtwigción de "bajo nivel" directamente en el model asíncrono.

PS no has citado el contenido de php.ini . Publicarlo y / o ajustarlo.