descargar - Largo tiempo hasta el primer byte para un archivo php vacío

document cakephp (4)

Tuve esa question unos meses. Ahora para aislar el problema probé un nuevo enfoque. Pongo un archivo vacío a mi servidor.

El nombre del archivo es "foobar.php". Su contenido es el siguiente:

<?php echo "hello world";

Pero cuando intento ingresar a example.com/foobar.php , obtengo

DNS 203 msegundos
Conecta 3,33 segundos.
Enviar 0 milisegundos
Tiempo hasta el primer byte 17.35 segundos
Recibe 1 milisegundos Tiempo total de carga 20.88 segundos

Luego puse otro archivo llamado "foobar.txt". Su contenido es el siguiente:

hello world<br/>

El tiempo de carga de foobar.txt es de aproximadamente 0,2 segundos.

Este sitio web está dentro de un alojamiento compartido, por lo que no puedo obtener un acceso raíz a Linux. Estoy tratando de averiguar qué hace que mi sitio sea lento.

Cuando obtengo estos resultados, tengo 60 visitantes en mi sitio. Y envían solicitudes AJAX cuando están activas. Cuando están activos, envían una solicitud AJAX casi cada 3 segundos.
Generalmente mi sitio web tiene 5-20 solicitudes por segundo.
Mi proveedor de hosting dice que no se produce una sobrecarga de CPU, generalmente es muy baja.
Le pregunté a la compañía de alojamiento por los límites de Apache. Obtengo estos valores para todo el servidor compartido:

MaxClients 300
MaxRequestsPerChild 4000
HilosPerChild 25

Las páginas example.com/mybigpage.php y example.com/foobar.php se abren casi al mismo tiempo.
Si la página tiene txt, jpeg u otras extensiones, se abren al instante. Si la extensión es php se abre muy lento.
CakePHP almacena los archivos de sesión dentro de la carpeta "/ httpdocs / app / tmp / session". Los archivos de sesión se eliminan después de dos horas de creación. Ahora hay 3653 archivos dentro de esa carpeta. El archivo más antiguo se creó hace 2,5 horas.
En mi configuración, el controlador PHP es el módulo Apache mod_php

Nueva Edición: Hablé con mi empresa de hosting. Y les dijo que "foobar.php" se abre casi en 20 segundos. Aunque ese archivo no tiene ningún código. Me dijeron que pusieron "foobar.php" en otros sitios web que usamos el mismo servidor. También probé "othersite.com/foobar.php". Se abrió al instante. Pero "mysite.com/foobar.php" se abrió casi en 15 segundos. ¿Qué haría este comportamiento? Usamos la misma configuración de PHP con otros sitios, pero se abren instantáneamente. ¿Puede ser debido a mis reglas de acceso .htaccess? U otra cosa?

Nuevo Edit2: mi proveedor me dijo que no existe ningún archivo "apd.so" dentro del servidor. Así que parece que no puedo usar APD.

¿Qué debo buscar para encontrar el cuello de botella?
¿Qué limitaría mi sitio?

Datos adicionales: del phpinfo, obtengo esto:

''./configure'' ''--prefix = / usr / local / lsws / lsphp5'' ''--build = x86_64-redhat-linux-gnu'' ''--host = x86_64-redhat-linux-gnu'' ''--target = x86_64-redhat-linux-gnu '''' --sysconfdir = / etc '''' --datadir = / usr / share '''' --includedir = / usr / include '''' --libdir = / usr / lib64 '''' --libexecdir = / usr / libexec '''' --localstatedir = / var '''' --sharedstatedir = / usr / com '''' --mandir = / usr / share / man '''' --infodir = / usr / share / info '''' - -cache-file = .. / config.cache '''' --with-libdir = lib64 '''' --with-config-file-path = / etc '''' --with-config-file-scan-dir = / etc /php.dd '''' --disable-debug '''' --with-pic '''' --disable-rpath '''' --without-pear '''' --with-bz2 '''' --with-curl '''' - with-exec-dir = / usr / bin '''' --with-freetype-dir = / usr '''' --with-png-dir = / usr '''' --without-gdbm '''' --with-gettext '''' --with-gmp '''' --with-iconv '''' --with-jpeg-dir = / usr '''' --with-openssl '''' --with-libexpat-dir = / usr / lib64 '''' --with -pcre-regex = / usr '''' --with-zlib '''' --with-layout = GNU '''' --enable-exif '''' --enable-ftp '''' --enable-magic-quotes '''' - enable-sockets '''' --enable-sysvsem '''' --enable-sysvshm '''' --enable-sysvmsg '''' --e nable-wddx '''' --with-kerberos '''' --enable-ucd-snmp-hack '''' --with-unixODBC = compartido, / usr '''' --enable-shmop '''' --enable-calendar '''' - -with-libxml-dir = / usr '''' --with-mysql '''' --with-mysqli '''' --with-gd '''' --enable-dom '''' --disable-dba '''' --without- unixODBC '''' --enable-xmlreader '''' --enable-xmlwriter '''' --with-mcrypt '''' --enable-mbstring '''' --with-litespeed '''' --enable-soap '''' --with-xsl '''' --with-pdo-mysql '''' --with-pdo-sqlite '''' --enable-sqlite-utf8 '''' --with-pspell '''' --with-sqlite = shared '''' --with-xmlrpc '''' --with-mhash '''' --enable-pdo '''' --with-imap '''' --with-imap-ssl '''' --without-suhosin '''' --with-tidy '''' --enable- zip '''' --enable-inline-optimization '''' --enable-gd-native-ttf '''' --enable-bcmath ''

Parece claro que se trata de un problema de PHP, ya que Apache no tiene problemas para entregar archivos estáticos. ¿Has intentado instalar APD desde PECL?

El uso de un generador de perfiles de PHP como APD le mostrará si el cuello de botella está en PHP y, si es así, dónde está. Por ejemplo, ¿está la lentitud en el marco que está utilizando? ¿O tal vez sólo una extensión deshonesta?

Parafraseando del manual oficial:

Con APD, solo agrega una instrucción en el punto de entrada:

<?php apd_set_pprof_trace(); ?>

APD volcará la información de perfil en * apd.dumpdir / pprof_pid.ext *.

Luego, pprofp consumirá sus archivos de volcado y le dirá qué métodos están consumiendo el tiempo de respuesta:

bash-2.05b$ pprofp -R /tmp/pprof.22141.0 Trace for /home/dan/testapd.php Total Elapsed Time = 0.00 Total System Time = 0.00 Total User Time = 0.00 Real User System secs/ cumm %Time (excl/cumm) (excl/cumm) (excl/cumm) Calls call s/call Memory Usage Name -------------------------------------------------------------------------------------- 100.0 0.00 0.00 0.00 0.00 0.00 0.00 1 0.0000 0.0009 0 main 56.9 0.00 0.00 0.00 0.00 0.00 0.00 1 0.0005 0.0005 0 apd_set_pprof_trace 28.0 0.00 0.00 0.00 0.00 0.00 0.00 10 0.0000 0.0000 0 preg_replace 14.3 0.00 0.00 0.00 0.00 0.00 0.00 10 0.0000 0.0000 0 str_replace

Si ninguno de los retrasos que ve aparece en el perfil, sugeriría que es un problema de configuración de PHP en todo el sistema (tal vez una extensión maliciosa o mal configurada). Pero supongo que es algo en el marco.

Si el mismo archivo PHP vacío se carga instantáneamente cuando se mueve a otro sitio, no puede ser debido a ningún marco o archivos incluidos porque no se han cargado en ese momento.

Puede ser un problema de configuración en el lado de PHP o Apache o puede deberse a las reglas de reescritura. Recomendaría probar lo siguiente:

1.) Si se permite la configuración de PHP por sitio, pida a la empresa de alojamiento que cambie el nombre de su php.ini específico a otro nombre, copie sobre php.ini desde otro sitio y reinicie Apache, vea si eso ayuda. Tuve un problema similar en Windows y se debió a problemas de acceso a archivos en php.ini, por lo que esto puede ayudar.

2.) Cambie temporalmente el nombre de .htaccess y acceda nuevamente al archivo php. Si el tiempo de carga disminuye, tendrá una condición de reescritura errónea u otra directiva. ¿Podrías también publicar los contenidos de tu .htaccess?

Sin la colaboración de su proveedor, no tiene oportunidad de descubrir qué está mal.

Yo sugeriría que es algo así como problemas de disco de la sesión.

Otro punto interesante es que su proveedor utiliza: http://www.litespeedtech.com/php-litespeed-sapi.html Nunca he oído hablar de eso antes.

Si su proveedor se atiene a lo que mjk le recomendó, simplemente debe cambiarlo. Parece que no los tienen bajo control.

Usted escribe que en el momento en que ocurre este problema, tiene varios clientes que realizan solicitudes AJAX cada 3 segundos. Esto hace que sea probable que todos los trabajadores de PHP disponibles en su servidor estén bloqueados por estas solicitudes AJAX. Su servidor web recibe su solicitud de /foobar.php y luego tiene que esperar hasta que un trabajador de PHP sea libre de procesar su solicitud.

Así que entre las posibles soluciones para su problema están (sin que sea más específico para lo que se necesita el AJAX, necesito mantener esto en general):

hacer que las solicitudes AJAX vayan a un archivo estático
asegúrese de que PHP realmente cierre la conexión cuando finalice la solicitud (AJAX), por ejemplo con un header("Connection: close"); (aunque esto podría no ser suficiente, consulte los comentarios en el manual de PHP sobre el manejo de la conexión )
reducir el número de solicitudes AJAX realizadas (a un número elaborado en colaboración con su proveedor)

En general, necesitará la ayuda de su proveedor para resolver esto. No escribió el método que utiliza su proveedor para servir PHP, por ejemplo, con fpm hay una configuración llamada process.max que puede limitar la capacidad de sus servidores web para procesar tantos archivos PHP en paralelo.