Dreamhost, PHP y consumo de CPU: Round 2

Autor: Armonth | El viernes 09 de febrero del 2007 @ 18:35.

Los que llevéis un tiempo leyendo blogs recordareis una polémica que hubo a finales del 2005 cuando varios usuarios experimentaron problemas con Dreamhost por culpa del consumo de CPU:

Historia previa

  1. Boja inició la discusión en La Maté por un yogur (blog desaparecido).

  2. Muchos blogs se hicieron eco (1, 2, 3, etcétera).

  3. Ricardo Galli indicó que el problema es usar PHP como CGI.

  4. Y los problemas se arreglaron (de nuevo, el blog de Boja desapareció) y se aprendieron algunas lecciones por el camino.

Pues bien, recientemente tuvimos un Round 2 en el que Boja volvió a tener problemas de CPU (ya tiene mala suerte xD).

Round 2: Desaparición de mod_php

Boja realizando unas pruebas puso La Maté por un Yogur como PHP 5.x (el cual sólo está como CGI) y cuando quiso volver a poner mod_php se encontró que la opción ya no existía. Aunque hay formas de forzar el uso de mod_php pueden generar problemas, así pues veamos qué ha pasado.

Según parece, la solución de usar mod_php es muy buena: en lugar de optimizar al máximo los sitios y evitar fallos que consumen mucho los usuarios pasaban de CGI a mod_php para evitar ser detectados por eso aumentaban los problemas en los servidores.

Al final, Dreamhost decidió que los nuevos dominios no tuvieran la opción de elegir mod_php. A los que nos ha pillado con el dominio ya registrado se nos mantiene la opción de usarlo.

Los dos principales motivos para elegir CGI según Dreamhost son:

  1. Con mod_php no se puede monitorizar cuánto consume cada usuario, por lo que no se puede evitar que abusen de la CPU.

  2. Mayor seguridad: con CGI ejecutas PHP con tu usuario en lugar de con el usuario de Apache.

Discutible como mínimo. ¿Significa eso que sitios de tamaño medio no pueden usar Dreamhost? No. Solamente hay que ver de qué modo está pensado: CGI para los usuarios con poco tráfico (== poco consumo de CPU) y FastCGI para los que tenemos un tráfico decente.

¿FastCGI?

FastCGI es una extensión abierta al CGI tradicional que como principal novedad mantiene en el servidor un único proceso persistente por cada programa FastCGI.

Recordemos que con CGI cada petición (cada visita) hace que Apache ejecute un fork+exec al PHP, es decir, ejecuta PHP cada vez que llega una visita.

Con FastCGI mantenemos un único proceso. Es casi como tener PHP ejecutandose como módulo de Apache. De media puedes esperar un consumo de 4 a 8 veces menor si lo comparamos con CGI.

Repito que no es mejor que mod_php pero no es mala opción aunque los CGI hoy en día tengan mala prensa, como curiosidad estuve haciendo pruebas con un conocido usando lighttpd+PHP 4.3 FastCGI y me gusto mucho el rendimiento -- pero ése no es el caso ahora --.

Por último, algunos scripts no son compatibles con FastCGI.

Me has convencido ¿cómo lo instalo?

Actualización: años después, Dreamhost usa FastCGI por defecto por lo que no hay que hacer nada.

Instrucciones (antigüo, desactualizado, conservado como recuerdo):

Siguiendo las instrucciones que dá Dreamhost:

Primero debemos ir al Panel de administración para elegir usar PHP 5 y activar soporte de FastCGI. Tiene que ser PHP5, según ellos PHP4 no funciona con FastCGI.

Podemos tener un subdominio con FastCGI y seguir usando el dominio con otra cosa, los cambios se aplican desde donde activas FCGI hacía abajo.

Luego tenemos que hacer un wrapper que cuando se reciba una petición la envíe al php5.cgi en memoria. Para ello vamos al directorio de nuestro dominio (para el ejemplo, fcgi.test.tld) y crearemos un fichero php5-wrapper.fcgi:

cd $HOME/fcgi.test.tld

cat > php5-wrapper.fcgi << "EOF"   
#!/bin/bash   
export PHP_FCGI_CHILDREN=3   
exec /dh/cgi-system/php5.cgi   
EOF

chmod u+x php5-wrapper.fcgi

El cat crea el fichero php5-wrapper.fcgi con las líneas que hay hasta el EOF. PHP_FCGI_CHILDREN es el número de procesos "hijo" a ejecutar, para la mayoría un valor de 3 es suficiente.

Opcionalmente: La ruta puesta en exec es un enlace al fichero php5.cgi, algunos servidores de Dreamhost no tienen dicho enlace por lo que debemos hacer un locate php5.cgi para encontrar el ejecutable y poner la ruta correcta.

Por último solamente tenemos que añadir en el mismo sitio que donde está en php5-wrapper.fcgi un fichero .htaccess (sirve el creado por WordPress) poniendo al principio del todo lo siguiente: 

Options +ExecCGI   
AddHandler fastcgi-script fcg fcgi fpl
AddHandler php5-fastcgi .php
Action php5-fastcgi /php5-wrapper.fcgi

Ahora debemos visitar el sitio por web y al hacerlo si ejecutamos ps aux deberíamos ver 3 procesos /dh/cgi-system/php5.cgi ejecutándose, si todo va bien ya está funcionando.

Comprobando que funciona y consume menos

Toca esperar 24 horas hasta aproximadamente las 5 de la tarde para que se genere un nuevo informe en $HOME/logs/resources/ ahí deberíamos ver el php5.cgi y su consumo.

Aseguraos de que son 24h enteras (si hace falta esperad 48h para ver el último informe) con FCGI activado que se puede mezclar consumo de antes de FCGI y de después sobretodo si ya usabas php5.

Problemas típicos

Lo peor que te puede pasar es que te de un Error 500, asegurate de los siguientes puntos:

  • Tus ficheros PHP, CGI y FCGI no tienen permisos de escritura para todo el mundo:

    chmod o-w *.php *.cgi *.fcgi

  • El nombre del fichero debe ser php5-wrapper.fcgi, de lo contrario los procesos seran matados (¡Ugh! ¡Que cruel! :P) al momento.

Nada, esto no tira

¡A Boja le paso! (lo dicho: tiene mala suerte xD). Mismos pasos que yo en el Planet Webdev (que sí usa FCGI) y no le funcionaba, para desactivar FCGI solamente hace falta que borres o comentes las 4 líneas añadidas al htaccess.

Si siguiendo los pasos no te funciona o al hacer el ps aux te aparece el php5.cgi pero con un <defunct> al lado es que algo en el servidor no está bien.

Resumiendo

  1. Si usas mod_php no lo toques.

  2. Si usas CGI y tienes poco consumo (pongamos de referencia 2000 segundos) o no te dan ningún toque no te preocupes.

  3. Si consumes mucho con CGI prueba FCGI.

Comentarios