Servidores Linux para aplicaciones Laravel en producción

Audité y reconfiguré servidores productivos Ubuntu donde corren las aplicaciones del equipo: Apache con mpm_event y HTTP/2, PHP-FPM, OPcache, InnoDB dimensionado a la RAM, colas con Supervisor y hardening.

Ubuntu

Apache

PHP-FPM

OPcache

MySQL/MariaDB

Supervisor

Hardening

Mi rol

Auditoría y configuración de servidores productivos; migración de tareas bloqueantes a colas.

Evidencia

Lo que hice

Auditoría de servidores productivos Ubuntu de 8 GB.
Apache de mpm_prefork a mpm_event, con HTTP/2.
PHP separado de Apache con PHP-FPM y pools con tope de workers.
OPcache, buffer pool de InnoDB y swappiness ajustados a la memoria disponible.
Tareas bloqueantes movidas a colas de Laravel, con workers bajo Supervisor.
Hardening de Apache y PHP, y protección de archivos sensibles.

Pendiente de medir

Latencia, memoria y swap antes y después de los cambios.

Siguiente paso

Línea base de rendimiento y monitoreo.
Llevar la configuración a código (Ansible o Terraform) y a contenedores.

La idea

En un servidor de 8 GB conviven Apache, PHP, la base de datos y los workers. El trabajo consistió en repartir la memoria a propósito: que cada componente tenga un límite y que un pico de tráfico se convierta en una espera corta, no en una caída.

Qué cambié

Apache mpm_event + PHP-FPM en lugar de prefork con PHP embebido: menos memoria por conexión y un tope explícito de procesos PHP. También habilitó HTTP/2.
Base de datos dimensionada a la máquina: el buffer pool de InnoDB se ajustó a lo que queda después de PHP, no a “toda la RAM”.
vm.swappiness bajo: el servidor prefiere RAM antes que swap.
OPcache: PHP deja de recompilar los scripts en cada petición.
Colas con Supervisor: lo que hacía esperar al usuario pasó a segundo plano, y Supervisor mantiene vivos los workers.
Hardening: Apache y PHP no anuncian su versión, hay cabeceras defensivas y los archivos como .env no son accesibles.

Lo que no afirmo

No medí el rendimiento antes de los cambios, así que no publico porcentajes de mejora. El siguiente paso es tener una línea base y monitoreo, y convertir esta configuración en infraestructura reproducible: es exactamente el camino hacia DevOps que estoy siguiendo.