5.2Rendimiento: caché, OPcache, Redis
Lo esencial en 30 segundos
- OPcache: el bytecode compilado se pone en caché — compilación una sola vez en lugar de cada petición, ganancia mayor casi gratuita.
- Caché aplicativa: almacenar los resultados costosos (Redis) para no rehacerlos — a menudo la palanca más impactante.
- Medir primero: perfilar para hallar el verdadero cuello (a menudo la base) — nunca optimización prematura.
Mini-caso hilado — Riad acelera su tienda en Constantina
La tienda reestructurada de Riad en Constantina va lenta en horas punta: la página de inicio tarda en responder. En lugar de reescribirlo todo, mide: el OPcache no está activado en producción, y las mismas consultas de catálogo solicitan la base sin cesar. Activa el OPcache y pone el catálogo en caché. Continuación del caso 5.1 — Riad optimiza lo que ha medido, no al azar.
Continuación del caso 5.1 — Riad aplica la regla de oro: medir primero, optimizar después.
1. OPcache: la ganancia casi gratuita
PHP es interpretado: en cada petición, el servidor compila el código (en «bytecode») antes de ejecutarlo. Rehacer esta compilación en cada petición, cuando el código no cambia, es despilfarro. El OPcache es una extensión (generalmente disponible) que pone en caché el bytecode compilado: se compila una vez, luego se reutiliza — una ganancia de rendimiento mayor y casi gratuita. Riad verifica que esté activado y bien configurado en producción (en desarrollo, a veces se desactiva para ver los cambios enseguida). Las versiones modernas de PHP aportan además importantes ganancias intrínsecas.
Reflejo: una aplicación PHP en producción sin OPcache es claramente más lenta sin motivo — es la optimización de base, antes que cualquier otra.
2. La caché aplicativa y Redis
La palanca más impactante en las aplicaciones reales es la puesta en caché: almacenar resultados costosos y poco cambiantes (consultas frecuentes, cálculos pesados, páginas o fragmentos, datos de API externas) para no rehacerlos en cada petición. Para una caché rápida y compartida, se usa a menudo Redis (o Memcached) — un almacenamiento en memoria, por tanto muy rápido, que sirve también para las sesiones o las colas de espera. Los frameworks (Laravel, Symfony) integran sistemas de caché fáciles de usar, con varios pilotos. Riad pone el catálogo en caché con una corta duración de vida: las peticiones repetidas ya no tocan la base.
Regla de elección: se cachea lo que es costoso de producir y soporta estar ligeramente diferido — con una estrategia de refresco clara.
3. Base, perfilado y buen método
La base de datos es a menudo el verdadero cuello: consultas lentas o no indexadas, y el famoso problema N+1 (frecuente con los ORM: una consulta por elemento de una lista en lugar de una sola — corregido por la carga agrupada de las relaciones, «eager loading»). Indexar las columnas buscadas y optimizar las consultas tiene a menudo el mayor impacto. Y el método que lo domina todo: el perfilado — medir antes de optimizar para identificar los verdaderos cuellos en lugar de optimizar a ciegas. Riad perfila antes de tocar el código: la lentitud venía de la base, no de sus bucles.
Principio transversal: no optimizar prematuramente. Código correcto y claro primero, medida cuando surge un problema, optimización focalizada después. Optimizar demasiado pronto hace perder tiempo y complica inútilmente.
🔎 Ejemplo concreto — Riad pone el catálogo en caché
Verificar el OPcache, luego cachear un resultado costoso.
query('SELECT id, nom, prix FROM produits')->fetchAll(PDO::FETCH_ASSOC);
file_put_contents($fichier, json_encode($lignes));
return $lignes;
}Lectura: se verifica la ganancia gratuita (OPcache), luego se evita rehacer lo costoso (caché con duración de vida).
Lección: en producción, esta caché viviría en Redis — compartida entre todos los procesos.
Vocabulario de la sección
- OPcache
- Extensión que pone en caché el bytecode PHP compilado, compilado una sola vez.
Ejemplo sencillo: Riad lo activa en producción: fin de la recompilación en cada petición.
Lo que no es: una caché de páginas HTML.
Reflejo: ¿el OPcache está activo en mi producción?
- Puesta en caché
- Almacenar los resultados costosos para no recalcularlos cada vez.
Ejemplo sencillo: El catálogo de Riad servido desde la caché, ya no desde la base.
Lo que no es: añadir servidores antes de cachear.
Reflejo: ¿qué consultas vuelven sin cesar idénticas?
- Redis
- Almacenamiento en memoria rápido, usado a menudo como caché compartida.
Ejemplo sencillo: Riad coloca allí el catálogo con una corta duración de vida.
Lo que no es: la base de datos principal ella misma.
Reflejo: ¿este resultado soporta estar ligeramente diferido?
- Problema N+1
- Una consulta por elemento de una lista en lugar de una sola consulta agrupada.
Ejemplo sencillo: Riad carga las opiniones de 50 productos de una vez, no en 50 consultas.
Lo que no es: una falta de memoria en el servidor.
Reflejo: ¿cuántas consultas salen para mostrar esta lista?
- Perfilado
- Medir para identificar los verdaderos cuellos antes de optimizar.
Ejemplo sencillo: Riad descubre que la lentitud viene de una consulta no indexada.
Lo que no es: optimizar sus bucles por intuición.
Reflejo: ¿he medido antes de tocar el código?
En la práctica — Optimizar una aplicación PHP
- Verifique que el OPcache esté activado y bien configurado (sobre todo en producción) — una ganancia de rendimiento mayor casi gratuita (bytecode compilado puesto en caché).
- Ponga en caché un resultado costoso (consulta frecuente) — en memoria o con Redis — y mida la ganancia; use el sistema de caché de un framework.
- Optimice la base: indexe las columnas buscadas, detecte y corrija el problema N+1 (carga agrupada de las relaciones) — a menudo el mayor impacto.
- PERFILE para identificar los verdaderos cuellos ANTES de optimizar (medir antes de optimizar); no optimice prematuramente (código correcto primero).
Guion listo para decir — justificar una optimización
«En Constantina, nuestra tienda se ralentiza en horas punta. He medido: el OPcache no está activo en producción y las consultas de catálogo saturan la base. Propongo dos gestos focalizados: activar el OPcache y poner el catálogo en caché con una corta duración de vida. Remedimos después, y solo tocamos la infraestructura si la medida lo justifica.»
A decir al responsable para hacer validar una optimización medida en lugar de una reescritura a ciegas.
Modelo copiar-pegar — ficha diagnóstico perf
PERF — DIAGNÓSTICO
SÍNTOMA : _______________ (¿cuándo? ___)
OPCACHE : ¿activo en producción? ___
MEDIDA : tiempo de respuesta ___ · consulta más lenta ___
CUELLO SOSPECHOSO : caché ausente / base (índice, N+1) / código : ___
ACCIÓN FOCALIZADA : OPcache / caché Redis / índice / eager loading : ___
REMEDIDA : antes ___ → después ___ · GANANCIA : ___Solo / presupuesto pequeño
Riad solo: OPcache + caché en archivo en las páginas costosas basta — Redis vendrá cuando el tráfico lo justifique.
TPE / equipo reducido
Indexar las consultas lentas primero: a menudo la ganancia más rápida, sin nueva infraestructura.
PYME en Constantina
Riad planifica las medidas en horas punta en Constantina, con un protocolo de remedida tras cada cambio.
Equipo que empieza
Pareja: uno perfila mientras el otro prepara la caché; revisión común de las medidas antes de toda optimización.
✓ Buenas prácticas
- Verificar el OPcache en producción antes de toda otra optimización (la ganancia gratuita).
- Poner en caché los resultados costosos; indexar y corregir el N+1.
- Medir (perfilar) antes de optimizar, y focalizar los verdaderos cuellos.
✗ Errores frecuentes
- Optimizar sus bucles por intuición sin medir (el cuello está en otra parte).
- Olvidar el OPcache en producción (lentitud sin razón).
- Poner en caché sin duración de vida ni estrategia de refresco (datos caducados).
Puntos clave
- OPCACHE: pone en caché el BYTECODE PHP compilado (compilación una sola vez en lugar de cada petición) — ganancia MAYOR casi gratuita. A activar/configurar, sobre todo en producción.
- PUESTA EN CACHÉ (a menudo lo más impactante): almacenar los resultados COSTOSOS (consultas frecuentes, cálculos, páginas) para no rehacerlos; REDIS (almacenamiento en memoria rápido). Los frameworks integran la caché.
- OPTIMIZACIÓN de la BASE (a menudo el verdadero cuello): indexar, optimizar las consultas, corregir el N+1 (carga agrupada). PERFILAR (medir) ANTES de optimizar (regla de oro).
- NO optimizar PREMATURAMENTE: código correcto y claro primero, MEDIR cuando surge un problema, luego optimización FOCALIZADA. Optimizar demasiado pronto = tiempo perdido + complejidad inútil.
Reto 48h — aplique mañana
Rellene la ficha diagnóstico para 1 lentitud real de su app: OPcache verificado, medida, cuello sospechado — sin tocar aún el código.
- Puedo explicar OPcache vs caché aplicativa en una frase.
- Mi ficha diagnóstico (medida antes de optimización) está rellena.
- Sé por qué la base es la primera sospechosa.
Preguntas frecuentes
¿Qué son el OPcache y la caché, y cómo mejorar el rendimiento de una aplicación PHP?
Dos mecanismos diferentes y complementarios. El OPcache resuelve un despilfarro propio de PHP: recompilar el código en cada petición. Pone en caché el bytecode compilado — se compila una vez, se reutiliza — ganancia mayor casi gratuita, a activar sobre todo en producción. La caché aplicativa resuelve otro despilfarro: rehacer operaciones costosas (consultas frecuentes, cálculos, páginas) cuando el resultado cambia poco. Se almacena el resultado (a menudo en Redis, en memoria, muy rápido) con una duración de vida. A ello se añaden la optimización de la base (índice, corrección del N+1 — a menudo el verdadero cuello) y el perfilado: medir para optimizar donde cuenta, nunca a ciegas.
¿Cómo saber cuándo y qué optimizar sin caer en la optimización prematura?
Regla de oro: no optimice antes de un problema real y medido. La optimización prematura hace perder tiempo, complica el código y falla el verdadero cuello (la intuición engaña). El método: código correcto y claro primero, medir (perfilado, tiempos de consultas) cuando surge un problema, optimizar focalizado donde cuenta (OPcache, caché, base), remedir para confirmar la ganancia. La mayor parte del código no necesita optimizarse: una pequeña parte concentra lo esencial del coste — la medida la designa.
¿Cuál es el primer reflejo de rendimiento en una app PHP en producción?