¿Qué configuraciones de Apache / PHP conoces y qué tan buenas son?

Quería preguntarle sobre los métodos de configuración de PHP / Apache que conoce, sus ventajas y desventajas. Comenzaré yo mismo:

---------------- PHP como módulo de Apache ----------------

Pros : buena velocidad ya que no necesita iniciar exe cada vez, especialmente en modo mpm-worker . También puede usar varios aceleradores PHP en este modo, como APC o eAccelerator.

Contras : si está ejecutando apache en modo mpm-worker, puede enfrentar problemas de estabilidad porque cada falla en cualquier script php conducirá a la inestabilidad de todo el grupo de subprocesos de ese proceso de apache. También en este modo, todos los scripts se ejecutan en nombre del usuario de apache. Esto es malo para la seguridad. La configuración de mpm-worker requiere PHP compilado en modo seguro para subprocesos. Al menos los repositorios predeterminados de CentOS y RedHat no tienen una versión PHP segura para subprocesos, por lo que en estos sistemas operativos debe compilar al menos PHP usted mismo (hay una manera de activar el mpm de trabajador en Apache). El uso de binarios PHP seguros para subprocesos se considera experimental e inestable. Además, muchas extensiones PHP no admiten el modo seguro para subprocesos o no se probaron bien en modo seguro para subprocesos.

---------------- PHP como CGI ----------------

Esta parece ser la configuración predeterminada más lenta que parece ser una "estafa" en sí misma;)

---------------- PHP como CGI a través de mod_suphp ----------------

Pros : suphp le permite ejecutar scpts de php en nombre del propietario del archivo de script. De esta manera, puede separar de forma segura diferentes sitios en la misma máquina. Además, suphp permite usar diferentes archivos php.ini por host virtual.

Contras : PHP en modo CGI significa menos rendimiento. En este modo, no puede usar aceleradores php como APC porque cada vez que se genera un nuevo proceso para manejar el script, la memoria caché del proceso anterior es inútil. Por cierto, ¿conoces la forma de aplicar un acelerador en esta configuración? Escuché algo sobre el uso de shm para caché de bytecode php. Además, no puede configurar PHP a través de archivos .htaccess en este modo. Deberá instalar P ECL htscanner para esto si necesita establecer varias opciones por script a través de .htaccess (directivas php_value / php_flag)

---------------- PHP como CGI a través de suexec ----------------

Esta configuración se ve igual que con suphp, pero escuché que es más lenta y menos segura. Se aplican casi los mismos pros y contras.

---------------- PHP como FastCGI ----------------

Pros : El estándar FastCGI permite que un solo proceso de php maneje varios scripts antes de que se elimine el proceso de php. De esta manera, obtienes rendimiento, ya que no es necesario activar un nuevo proceso de php para cada script. También puede usar aceleradores PHP en esta configuración (consulte la sección contras para obtener comentarios). Además, FCGI casi como suphp también permite que los procesos php se ejecuten en nombre de algún usuario. mod_fcgid parece tener el soporte fcgi más completo y la flexibilidad para apache.

Contras : El uso del acelerador php en modo fastcgi conducirá a un alto consumo de memoria porque cada proceso PHP tendrá su propio caché de bytecode (a menos que haya algún acelerador que pueda usar memoria compartida para el caché de bytecode. ¿Existe?). FastCGI también es un poco complejo de configurar. Necesita crear varios archivos de configuración y hacer algunas modificaciones de configuración.

Parece que fastcgi es la configuración PHP más estable, segura, rápida y flexible, sin embargo, es un poco difícil de configurar. Pero, puede ser, me perdí algo?

¡Los comentarios son bienvenidos!

Ejecutar PHP a través de FastCGI sin duda le dará la mayor flexibilidad. No solo puede usar con seguridad un Apache mpm-worker, sino que también puede usar otro servidor web por completo (por ejemplo, nginx).

Pero incluso cuando se queda con Apache, "PHP vía FastCGI" no es, por el momento, una opción, sino al menos dos: mod_fastcgi, mod_fcgid. Además de eso, puede usar procesos FastCGI dinámicos, estáticos o externos; con o sin suexec. Y luego está el administrador de procesos FastCGI interno de PHP, que ahora se reemplaza por el muy agradable PHP-FPM en PHP 5.3. Todas esas opciones tienen diferentes pros y contras y pueden conducir a diferentes problemas.

Dada la opción, elegiría mod_fastcgi con PHP-FPM en este momento, principalmente porque permite configuraciones extremadamente versátiles y estables.

Realmente no respondo a su pregunta, pero no entiendo esto acerca de que FastCGI sea difícil de configurar. Es diferente a los otros métodos que debería reemplazar (mod_php, mod_python, ...), por lo que puede ser necesario reescribir una parte del código. Esa puede ser la parte difícil, pero para configurar Apache, al menos, creo que es muy fácil. Como ejemplo, estaba probando una aplicación WSGI en python, y quería ver cómo funcionaba con todos los protocolos que WSGI admite. Aquí está el archivo de host virtual con las configuraciones para todos los protocolos (con mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

No me parece complejo. Claro, FastCGI admite muchas opciones y puede ser modificado hasta la muerte, pero ese es otro asunto.

Para ejecutar es como un usuario diferente, use suexec y FastCGIWrapperluego se convierte en:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

Y vea este enlace para un php.ini personalizado, pero debería poder especificarlo con la -initial-envopción, es decir

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/

Un buen candidato es: El Apache 2 ITK MPM

apache2-mpm-itk (solo mpm-itk para abreviar) es un MPM (Módulo de procesamiento múltiple) para el servidor web Apache. mpm-itk le permite ejecutar cada uno de sus vhost bajo un uid y gid separados; en resumen, las secuencias de comandos y los archivos de configuración para un vhost ya no tienen que ser legibles para todos los otros vhosts.

Ha trabajado muy bien para uno de nuestros clientes con cientos de VirtualHosts con una gran cantidad de visitantes.

Obtiene todos los Pros de ejecutar PHP como módulo y resuelve algunos de los inconvenientes.

Para mí, la pregunta es cuál es el propósito del servidor web. ¿Está sirviendo a más de un host virtual? Si es así, debe sacrificar el rendimiento por seguridad aislada. Sí, el rendimiento se ve afectado, pero con el hardware de hoy en día todavía debería tomar bastante tráfico para generar problemas de rendimiento importantes.

Si el rendimiento es tan importante, ejecute el sitio en un servidor VPS o dedicado y configúrelo para el rendimiento.