Y es que a veces encontraremos que nuestra aplicación tiene unos requisitos mínimos que el servidor no cumple. Pongamos por ejemplo que queremos instalar prestashop que tiene ciertos requisitos mínimos y que por algún motivo nuestro hosting no satisface.

Cómo configurar variables de PHP desde .htaccess

Hay varias formas de actuar sobre estas variables, pero tal y como reza el título de esta entrada hoy vamos a hacerlo con el archivo .htaccess, y para ello utilizaremos la orden php_value. Su sintaxis es muy sencilla:

php_value + variable_php + valor.

Un ejemplo podría ser que necesitamos que la variable memory_limit esté configurada en 64M y el servidor la tiene configurada en 32M, o quizás el max_input_vars está configurado en 500 y nuestros requisitos mínimos son 1.000. Para ello incluiríamos las siguientes líneas en el archivo .htaccess:

php_value memory_limit 64M
php_value max_input_vars 1000

O supongamos que queremos mostrar los errores de PHP de nuestra aplicación. Podemos hacerlo desde el archivo .htaccess:

php_value error_reporting 7
php_flag display_errors On

Dónde colocar las líneas dentro del archivo .htaccess

Personalmente me gusta colocar este tipo de sentencias al comienzo del archivo .htaccess, justo detrás de los comentarios:

# Comentarios habituales en archivos .htaccess

# variables php
php_value error_reporting 7
php_flag display_errors On

<IfModule mod_rewrite.c>
<IfModule mod_env.c>
SetEnv HTTP_MOD_REWRITE On
</IfModule>

RewriteEngine on
...

Créditos, referencias y artículos relacionados

• Aumentar el límite de memoria de un script en PHP
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP
• Servidor Web en Raspberry PI y Ubuntu Mate
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Habilitar módulos en Apache 2 sobre Ubuntu

Estoy seguro de que a muchos de vosotros os suena lo siguiente: te dispones a instalar un servidor web, abres la consola de Linux, instalas Apache, y cuando buscas el paquete de PHP te encuentras que tienes varias opciones: php7.2, php7.2-cgi, php7.2-fpm o libphp7.2-embed. Dudas sobre cual elegir pero no tienes tiempo o ganas de investigar, sabes que el paquete php7.2 funcionará con total seguridad, así que lo instalas y continuas con la siguiente tarea.

Si has vivido esta situación, no te sientas culpable, no tengas remordimientos de conciencia, no estás solo, somos muchos los que hemos actuado así, pero sigue leyendo y la próxima vez podrás elegir la mejor opción para tus necesidades.

Handlers en Apache

Según la web de Apache, un handler es «una representación interna de Apache de una acción que se va a ejecutar cuando hay una llamada a un fichero», y continua «Generalmente, los ficheros tienen handlers implícitos, basados en el tipo de fichero de que se trata». Esto, traducido al cristiano y llevado al ámbito de PHP significa que cuando Apache detecta un fichero PHP hará uso de los handlers para conectar con el intérprete y que éste realice las tares oportunas.

Handlers para PHP

Ya sabemos que es un handler, repasemos ahora las principales opciones existente para que Apache pueda interpretar los archivos PHP.

DSO ó mod_php

Probablemente habrás escuchado hablar de mod_php pero quizás no de DSO. Mod_php es como se conoce comúnmente al manejador DSO (Dynamic Shared Object).

Es la opción más habitual en entornos de desarrollo o locales, si buscamos en internet como instalar PHP sobre Apache en Linux la mayoría de resultados nos propondrán este sistema, y para muestra un botón: Servidor Web en Raspberry PI y Ubuntu Mate.

Con mod_php el intérprete de PHP es ejecutado directamente por Apache como un módulo, lo que evita tener que realizar llamadas a procesos externos. Esto es una ventaja en cuanto que la comunicación entre ambos es muy ágil y nos permite obtener un gran rendimiento.

Otra característica de este sistema es que el intérprete PHP es cargado al arrancar cada proceso de Apache, incluso cuando el contenido a servir no contiene código PHP alguno. Este hecho provoca que obtengamos un mejor rendimiento en detrimento del consumo de recursos del sistema, convirtiéndolo en una mala opción para sites con mucho tráfico.

También es importante destacar que PHP hereda los permisos del usuario de Apache. Esto implica que nobody será el propietario de cualquier archivo creado por PHP, pudiendo generar algunos conflictos de permisos. No obstante con una mínima configuración podemos evitar este problema, podéis ver como hacerlo en el artículo Archivos y permisos de usuario en Apache 2 y Linux.

Ventajas de DSO

• Fácil instalación y configuración.
• Buen rendimiento.

Inconvenientes de DSO

• Alto consumo de recursos.
• Los archivos creados por PHP pertenecen a Apache.

CGI

CGI son las siglas de Common Getway Interface. Como su propio nombre indica es una interface y su cometido es permitir a Apache interactuar con programas externos, en este caso con PHP. Es un sistema que prácticamente podemos denominar como legacy y está cada vez más en desuso debido a su pobre rendimiento y a la existencia de alternativas más modernas y eficientes.

Al utilizar esta interface, cada petición de PHP inicia un proceso independiente que es finalizado cuando concluye su labor. Este modus operandi consigue que CGI sea muy eficiente en el consumo de memoria pero pobre en rendimiento. En sitios web con alto tráfico el sistema de creación y destrucción de procesos implica un uso de procesador demasiado elevado, por lo que no es nada recomendable para este tipo de sites.

Y al igual que con DSO, Apache será el propietario de lo archivos que generemos o subamos al servidor haciendo uso de PHP, pero ya hemos visto que este problema tiene fácil solución.

Ventajas de CGI

• Fácil de instalar y configurar.
• Consumo de recursos moderado en sites con poco tráfico.

Inconvenientes de CGI

• Rendimiento pobre.
• Alto consumo de procesador en sites con tráfico elevado.
• Los archivos creados por PHP pertenecen a Apache.

FastCGI

Podemos decir que FastCGI es la evolución de CGI, y surge por la necesidad disponer de un sistema con las ventaja de Common Getway Interface pero minimizando sus inconvenientes.

Al contrario que CGI, FastCGI mantiene la sesión abierta de forma persistente y no la cierra una vez que ha concluido el proceso por el que la abrió. Con esto se consigue un rendimiento similar a DSO a costa de elevar el consumo de memoria pero manteniéndolo por debajo de éste.

Una gran ventaja de FastCGI es que podemos configurar nuestro servidor para que trabaje con múltiples versions de PHP, lo que es particularmente útil cuando en una misma máquina tenemos aplicaciones que requieren versiones distintas de PHP.

Otra característica muy interesante es que podemos separar el host dónde corre Apache del host qué interpreta PHP, ofreciéndonos una gran versatilidad en el diseño de nuestro sistema.

Por último y haciendo referencia al propietario de los archivos creados por PHP, FastCGI hace uso de suEXEC para permitir definir la propiedad de los archivos. Esto es particularmente útil en entornos compartidos dónde es posible configurar distintos propietarios para distintos sites

Ventajas de FastCGI

• Buen rendimiento.
• Consumo de recursos moderado.
• Posibilidad de ejecutar Apache y PHP en distintos hosts.
• Posibilidad de trabajar con distintas versiones de PHP.
• Posibilidad de definir el propietario de los archivos.

Inconvenientes de FastCGI

• Mayor complejidad de configuración.

FPM

FPM o FastCGI Process Manager ha sido el último en llegar, y no es más que una implementación de FastCGI con varias características orientadas a la mejora del comportamiento para sitios web con mucho tráfico.

Cómo la diferencia entre FastCGI y FPM comienzan a adentrarse en un terreno muy técnico, no entraremos en mucho detalle, ero si mencionaremos algunas de estas mejoras:

• Manejo avanzado para detener/arrancar procesos de forma fácil.
• Posibilidad de iniciar hilos de procesos con diferentes uid/gid/chroot/environment.
• Escuchar en diferentes puertos.
• Usar distintos php.ini
• Uso de safe_mode.

Si quieres ver la lista completa de estas ventajas puedes hacerlo en la página dedicada a FPM en php.net.

Ventajas de FPM

• Buen rendimiento.
• Consumo de recursos moderado.
• Todas las ventajas de FastCGI.
• Más opciones de configuración que FastCGI.

Inconvenientes de FPM

• Mayor dificultad de instalación y configuración.

Tabla comparativa

Para intentar ser prácticos, podemos resumir lo que hemos visto en una tabla comparativa, que si bien carece de muchos matices puede darnos una visión bastante clara con tan solo un vistazo.

mod_php, CGI, FastCGI ó FPM, cuál es mejor?

Y la respuesta que muchos esperaréis después de leer (o no) esta entrada es: cuál es mejor? Y la respuesta más habitual a este tipo de preguntas es: para qué?

Para entornos de desarrollo, entornos de prueba o para pequeñas intranets sin excesiva carga recomendaría DSO. Es fácil de configurar, rinde bien y no tendremos problemas de recursos. El único motivo por el que me decantaría por otra opción sería si necesitáramos tener más de una versión de php corriendo en la misma máquina. En tal caso la opción más apropiada sería FastCGI.

Si nos vamos al lado opuesto, sites con muchísimo tráfico, dónde confieso que no tengo ninguna experiencia, parece que la mejor opción es FPM, por: rendimiento, consumo de recursos y versatilidad.

Y entre el espacio que dejan las dos situaciones propuestas es quizás dónde mejor encajaría FastCGI, asumiendo que los motivos que influyen en la decisión última no permiten trazar líneas delimitadoras claras y recomendar hasta aquí esta opción y a partir de aquí la otra. En su lugar nos dejan una amplia gama de grises en función de las características del entorno.

Para acabar, personalmente intentaría no utilizaría CGI, pues no encuentro ninguna característica diferenciadora que compense el peor rendimiento y mayor consumo de recursos.

Créditos, referencias y artículos relacionados

• Imagen de portada por Arek Socha en pixabay.
• Servidor Web en Raspberry PI y Ubuntu Mate.
• Archivos y permisos de usuario en Apache 2 y Linux.
• Habilitar módulos en Apache 2 sobre Ubuntu.
• Handlers en Apache.
• RFC de Common Gateway Interface.