LAMP, LEMP o Nginx + Apache: ¿qué pila web elegir?

LAMP y LEMP — dos conjuntos clásicos de software para sitios en PHP: Linux, servidor web, base de datos y PHP. Se diferencian en el servidor web: en LAMP es Apache, en LEMP — Nginx. En la práctica lo importante es otra cosa: cómo exactamente el servidor web ejecuta PHP. De ello dependen el consumo de memoria, el comportamiento bajo carga y si necesita un segundo servidor web.

De qué consta la pila

En lugar de MySQL en ambas pilas se puede usar PostgreSQL: la mayoría de las aplicaciones PHP modernas lo soportan. El nombre de la pila no cambia por eso.

Cómo Apache ejecuta PHP

Apache tiene dos maneras de arrancar PHP.

mod_php. El intérprete de PHP está integrado directamente en los procesos de Apache. Es la opción más simple, pero no encaja bien con los modelos multihilo de Apache. Las extensiones de terceros de PHP no siempre son seguras para hilos, por eso con mod_php normalmente se usa el modelo de procesamiento (MPM) prefork. Según la documentación de Apache, prefork es «un servidor no multihilo con procesos prearrancados», y es adecuado para sitios que necesitan evitar hilos debido a bibliotecas que no están diseñadas para multihilo. Cada proceso atiende una conexión, por lo que con cien visitantes concurrentes hacen falta cien procesos, y en cada uno hay todo el intérprete de PHP, incluso si se solicita una imagen.

PHP-FPM. PHP funciona como un servicio separado con su propio pool de procesos, y Apache le pasa las peticiones a través del módulo mod_proxy_fcgi. Entonces Apache puede trabajar en el modelo event: según la documentación, después de enviar la respuesta el hilo de trabajo cede la conexión a un hilo oyente separado, y las conexiones keep-alive inactivas no ocupan los hilos de trabajo. Apache sirve la estática por sí mismo, sin invocar a PHP.

Vínculo mínimo de Apache y PHP-FPM a través de socket:

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

La ruta al socket depende de la versión de PHP y del distribuidor. De aquí la principal conclusión: la afirmación «Apache crea un proceso por cada petición» es válida solo para prefork. Apache con event y PHP-FPM es por su diseño cercano a Nginx con PHP-FPM.

Cómo Nginx ejecuta PHP

Nginx no sabe ejecutar PHP por sí mismo — no hay un módulo integrado. Siempre pasa las peticiones PHP a PHP-FPM mediante el protocolo FastCGI, y sirve la estática directamente. Configuración mínima:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

El archivo snippets/fastcgi-php.conf está en los paquetes de Debian y Ubuntu; en otras distribuciones se definen manualmente los parámetros FastCGI necesarios.

La diferencia práctica principal — .htaccess

Apache lee archivos .htaccess en los directorios del sitio: allí van reglas de redirección, protección de directorios, ajustes de caché. Muchos CMS, sobre todo WordPress y Bitrix, cuentan con este mecanismo y escriben sus reglas en .htaccess. Nginx no lee .htaccess: todo se define en la configuración del servidor, y tras los cambios hay que volver a cargarla.

Para el administrador es una ventaja: la configuración está en un solo lugar y no se comprueba en cada petición. Para el propietario de un sitio con un CMS listo para usar puede ser un problema: las reglas de .htaccess habrá que trasladarlas manualmente a la configuración de Nginx, y al actualizar plugins hay que vigilar que no se pierda nada.

Híbrido: Nginx delante de Apache

En el esquema híbrido Nginx acepta conexiones en los puertos 80 y 443, termina HTTPS, sirve la estática y pasa las demás peticiones a Apache, que escucha un puerto interno, por ejemplo 127.0.0.1:8080. El sitio sigue usando .htaccess.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

En el lado de Apache se necesita el módulo mod_remoteip, para que en los registros y en la aplicación se vea la dirección real del visitante y no 127.0.0.1. La aplicación debe entender la cabecera X-Forwarded-Proto, de lo contrario, si entra por HTTPS, puede entrar en un redireccionamiento infinito a HTTPS.

Este esquema lo usan por defecto muchos paneles de control de hosting. Más detalles sobre proxy inverso con Nginx y cómo elegir entre Nginx, Apache, HAProxy, Caddy y Traefik están en el artículo «Caddy vs. Traefik vs. HAProxy vs. Nginx vs. Apache».

Cuándo elegir qué

El híbrido se justifica cuando se necesita .htaccess. Si el sitio no depende de él, un segundo servidor web es memoria de más, una capa más donde puede romperse la configuración y un paquete más para actualizar.

Errores típicos

• mod_php con el modelo event. Los paquetes de Debian y Ubuntu al instalar libapache2-mod-php cambian Apache a prefork. Si luego se activa manualmente event, Apache puede negarse a arrancar o funcionar de forma inestable. Con event use PHP-FPM.
• MaxRequestWorkers no calculado según la memoria. En prefork cada proceso ocupa decenas de megabytes. La documentación de Apache dice claramente: el valor debe ser lo bastante grande para la carga esperada y lo bastante pequeño para que haya memoria RAM para todos los procesos. Si no, el servidor empieza a usar swap.
• Apache en el híbrido escucha la interfaz externa. El puerto 8080 debe ser accesible solo desde 127.0.0.1, de lo contrario se puede acceder al sitio evitando Nginx.
• Diferentes versiones de PHP en los pools. Cada versión de PHP-FPM tiene su propio socket; compruebe que el servidor web apunta al correcto.
• Estática a través de PHP. Si todas las peticiones, incluidas las imágenes, van a PHP-FPM, el servidor gasta recursos inútilmente. Las reglas para la estática deben estar antes de la regla para PHP.