Caché Realpath de PHP: un acelerador subestimado para el rendimiento de PHP

La opción, a menudo pasada por alto, que permite agilizar las solicitudes PHP se llama PHP Realpath Caché: almacena las rutas resueltas en la memoria RAM y reduce las costosas consultas al sistema de archivos en las llamadas a `include` o `require`. En proyectos con Symfony, Laravel o una configuración grande de WordPress, consigo aumentar el rendimiento con una configuración adecuada de Realpath. Actuación es cuantificable y mantengo el número de llamadas al sistema por solicitud considerablemente más bajo.

Puntos centrales

• Más sencillo Hebel: Realpath almacena las resoluciones de rutas y reduce el número de accesos al sistema de archivos.
• Por trabajador: Cada proceso de PHP-FPM gestiona su propia caché de Realpath.
• Talla A tener en cuenta: una caché demasiado pequeña provoca «thrashing» y ralentiza las solicitudes.
• TTL Determina la periodicidad de actualización: TTL largo para implementaciones estables, corto para enlaces simbólicos y secretos.
• Monitoreo: Las funciones realpath_cache_get() y size() muestran la carga y los huecos.

Qué hace exactamente la caché de Realpath

Cada vez que se utiliza «include», «require» o «file_get_contents», PHP convierte las rutas relativas en absolutas y almacena estos resultados en el Cache. Si vuelve a llegar la misma ruta, leo el resultado de la memoria y me ahorro el costoso viaje a la sistema de archivos. Este mecanismo reduce notablemente las llamadas al sistema, sobre todo cuando la carga automática de Composer carga muchas clases y archivos de configuración. Importante: la caché de Realpath existe por cada proceso, por lo que cada trabajador de PHP-FPM solo se beneficia de ella tras unas cuantas solicitudes, cuando ya ha creado su propia caché. De este modo se produce un efecto de aceleración constante que resulta especialmente beneficioso en condiciones de alta carga.

Por qué la caché es importante en los grandes marcos de trabajo

Los grandes frameworks y los numerosos plugins generan un sinfín de por cada solicitud Accesos a archivos, que sin el almacenamiento en caché tendrían que resolver las rutas cada vez desde cero. Si la caché de Realpath es demasiado pequeña, las entradas más antiguas se sustituyen por otras nuevas, y observo puro Thrashing. El resultado son operaciones repetidas de estadísticas y búsqueda que consumen tiempo y sobrecargan las E/S. En la práctica, esto permite reducir el número de llamadas al sistema por solicitud en aproximadamente 5-15 %, lo que supone un ahorro considerable cuando la tasa de solicitudes es elevada. Cuanto más modular sea la aplicación, mayor será el efecto multiplicador que se consigue con una caché de Realpath correctamente dimensionada.

Así es como calculo el tamaño adecuado de la caché

Primero cuento las rutas únicas de una solicitud típica, calculo la longitud media de las rutas y sumo unos 128 bytes por cada entrada. Sobrecarga. A partir del número, la longitud de la ruta y la sobrecarga, calculo un valor para realpath_cache_size que sea suficiente Tampón ofrece. Muchos proyectos grandes ocupan entre 4 y 16 MiB, y los monorepos muy extensos incluso más. Es importante que la caché no se quede al límite, ya que, de lo contrario, perdería su utilidad al tener que vaciarla constantemente. Aumento el tamaño por etapas, observo la utilización y lo ajusto en consecuencia.

Configuraciones recomendadas y valores de ejemplo

Los valores predeterminados proceden de una época en la que las bases de código eran pequeñas y, a menudo, ya no se ajustan a las necesidades actuales Configuraciones. Para muchas aplicaciones productivas, configuro realpath_cache_size entre 4096K y 16384K y amplío realpath_cache_ttl a un valor comprendido entre 360 y 600 Segundos o más. Los factores decisivos son el tamaño del proyecto, la frecuencia de implementación y las características del sistema de archivos. La siguiente tabla ofrece unos valores de referencia útiles como orientación y ayuda a dar los primeros pasos en el ajuste del rendimiento. A continuación, ajusto las cifras mediante la supervisión y las pruebas de carga.

Configuración	Incumplimiento frecuente	Buenos valores iniciales	Efecto esperado
tamaño_cache_ruta_real	4096 K (4 MiB)	4096 K–16 384 K	Reducido Thrashing cuando hay muchos archivos
realpath_cache_ttl	120–600 s	360–900 s	Más largas Retenciones de caché, menos disoluciones sucesivas

Ejemplos en el archivo php.ini: realpath_cache_size = 4096K y para grandes marcos de trabajo realpath_cache_size = 16384K. Para la vida útil, suelo utilizar realpath_cache_ttl = 360 o superior en el caso de lanzamientos poco frecuentes. De este modo, las rutas permanecen en la memoria a lo largo de numerosas solicitudes sin tener que volver a validarse constantemente.

Elegir bien el TTL, en función de la implementación

El TTL adecuado depende en gran medida del proceso de implementación y del uso de Symlinks . Cuando cambio de versión mediante la rotación de enlaces simbólicos, la caché no debe mostrar rutas obsoletas, por lo que establezco un TTL corto o provoqué un reinicio de FPM tras el Despliegue. En entornos de Kubernetes que utilizan secrets o ConfigMaps como volúmenes, reduzco considerablemente el TTL o desactivo temporalmente la caché de Realpath. Por el contrario, los entornos de alojamiento web más estáticos se benefician de TTL más largos, ya que las rutas rara vez cambian. De este modo, consigo un equilibrio entre la actualidad y la velocidad en función del entorno.

Supervisar y verificar

Lo compruebo regularmente con realpath_cache_get(), qué rutas hay en el Cache se encuentran, y con realpath_cache_size(), cuánto espacio de almacenamiento ocupa. Si el uso se acerca al tamaño configurado, aumento el Capacidad Poco a poco. Si la caché se llena con extrema rapidez, lo interpreto como una señal de que hace falta más memoria o de que el TTL es demasiado corto. Tras instalaciones importantes de plugins o actualizaciones del framework, vuelvo a comprobarlo. Solo quien conoce las cifras puede tomar decisiones acertadas a la hora de optimizar el sistema.

Efecto cuantificable: así es como mido las llamadas al sistema y las latencias

Para garantizar que el ajuste sea fiable, realizo mediciones antes y después de los cambios. En Linux, registro las llamadas al sistema de archivos por solicitud con strace o perfecto, ya sea en un único trabajador FPM o en la CLI.

• Solicitud individual (CLI): strace -c -o /tmp/strace.txt php public/index.php ofrece una visión general del número de stat(), openat() y lstat() que se generen.
• Añadir un trabajador de FPM: strace -fp -e trace=file -o /tmp/strace-fpm.log Muestra únicamente las llamadas relacionadas con archivos. Antes, con P.D. Determinar el PID del worker.
• Prueba de carga: Con herramientas como de o hola Simulo una carga y comparo las latencias P95/P99 con diferentes tamaños de caché.

Al mismo tiempo, hago que PHP me muestre el uso de la caché, por ejemplo, en un punto final de depuración o a través de la CLI:

<?php
$entries = realpath_cache_get();
$size    = realpath_cache_size();
printf("Entradas: %d, Utilizadas: %d bytes (%.2f MiB)\n", count($entries), $size, $size/1048576);

Así es como sé si el aumento de la tamaño_cache_ruta_real de hecho, reduce los errores y las llamadas al sistema de archivos, en lugar de limitarse a ocupar memoria RAM. En el mejor de los casos, la tasa de aciertos aumenta, mientras que las latencias P95 se reducen notablemente.

Así es como precaliento la caché de Realpath de forma específica

Dado que la caché se crea por cada trabajador, merece la pena un Calentamiento tras la implementación o el reinicio. El objetivo es que los archivos «include» más frecuentes se almacenen en la caché lo antes posible, antes de que llegue el tráfico real de los usuarios.

• Repeticiones de solicitudes: Tras el lanzamiento, realizo automáticamente una serie de pruebas en una serie de URL típicas (interfaz de usuario, panel de administración, API).
• Inicialización de la CLI: Un breve script de arranque carga las rutas principales (cargador automático, kernel, configuración, rutas).

<?php
// warmup.php
require __DIR__.'/vendor/autoload.php';  // Composer
require __DIR__.'/config/bootstrap.php'; // Depende del proyecto
require __DIR__.'/public/index.php';     // Controlador principal (puede activar una ejecución breve)
echo sprintf("Se han preparado entradas %d, se han utilizado bytes %d\n",
    count(realpath_cache_get()), realpath_cache_size());

Aunque este «warm-up» no cubre todas las solicitudes reales, almacena las rutas más utilizadas y acorta notablemente la fase inicial de arranque en frío de cada trabajador.

Interacción con OPcache y la caché del sistema de archivos

OPcache acelera la ejecución de los archivos PHP, mientras que Realpath acorta la ruta de acceso al archivo, por lo que combino ambos Técnicas. Para la configuración de OPcache, utilizo valores probados y me remito a fuentes fiables Optimización de OPcache, para que el código byte y las rutas interactúen de forma óptima. Además, Realpath se beneficia de una caché del sistema operativo «caliente», que proporciona rápidamente búsquedas en directorios y metadatos. De este modo, evito tiempos de espera duplicados durante la carga y el análisis sintáctico. Quien coordine ambos niveles consigue mejoras notables en los tiempos de respuesta.

Aprovechar al máximo la carga automática de Composer

El autoloader de Composer es un factor clave en la resolución de rutas. Cuanto más determinista sea su funcionamiento, más fácil será el trabajo de la caché de Realpath.

• Optimizar Classmap: composer dump-autoload -o Reduce los escaneos de directorios y las búsquedas repetidas.
• Mantener la carga automática estrictaCon classmap-autoritativo (Configuración del proyecto): evito los «fallbacks» innecesarios que, de otro modo, provocarían resoluciones de ruta adicionales.
• Organizar la estructura: Las jerarquías de carpetas planas y coherentes, junto con un número reducido de casos especiales (por ejemplo, inclusiones que abarcan varios módulos o clientes), estabilizan la carga de la caché.

El resultado: menos rutas diferentes por solicitud, mayor reutilización en la caché de Realpath y, por lo tanto, menores costes de E/S.

FPM y presupuesto de memoria: qué es realista por trabajador

Dado que la caché de Realpath existe por cada proceso, el tamaño configurado se multiplica por el número de trabajadores de FPM. Por eso, tengo previsto un presupuesto:

• Ejemplo: 12 trabajadores × 8 MiB = 96 MiB de «Realpath-Kopf»; a esto hay que añadir la caché OPcache, el montón de PHP y la sobrecarga de las extensiones.
• Equilibrar: Si OPcache dispone de suficiente espacio, Realpath puede obtener unos MiB más, o al revés.
• Específico para piscinas: Los distintos grupos de FPM (Front, Admin, API) pueden tener diferentes tamaños de Realpath, en función de la huella de código correspondiente.

Si el código crece con cada versión, crece también el tamaño_cache_ruta_real-Por lo general, esto va de la mano de la demanda. Por eso compruebo periódicamente la ocupación máxima bajo carga, no solo en reposo.

Casos especiales: enlaces simbólicos, contenedores y NFS

Cuando realizo implementaciones de enlaces simbólicos, preparo una breve TTL o reinicia FPM tras la implementación para que todos los workers carguen las rutas actualizadas. En contenedores con volúmenes mutables, me aseguro de que la caché no contenga datos obsoletos Objetivos lo soluciono ajustando el TTL. En NFS, además, se recomienda una estrategia de OPcache bien definida y el menor número posible de cambios de directorio. Si las rutas cambian durante la ejecución, en caso de duda las vacío de forma selectiva con clearstatcache(true) incluida la parte de Realpath. Unas reglas de implementación claras evitan que se produzcan inconsistencias entre los distintos trabajadores.

Obstáculos y limitaciones habituales

Dado que la caché es específica de cada proceso, cada uno debe Trabajador En primer lugar, hay que recopilar las rutas antes de que el efecto surta efecto. En configuraciones con fuertes restricciones de open_basedir, la caché de Realpath funciona de forma limitada, por lo que tengo esto en cuenta. Límites durante la planificación. Las cachés demasiado pequeñas provocan «thrashing», mientras que las demasiado grandes desperdician RAM; busco el punto óptimo mediante mediciones. Además, tengo en cuenta que Realpath no es una caché de metadatos ni de contenido, sino que almacena exclusivamente resoluciones de rutas. Quien tenga expectativas erróneas pasará por alto las causas que se encuentran en otros lugares.

Seguridad operativa: fallos típicos y comprobaciones rápidas

Hay algunos síntomas que indican claramente problemas con Realpath y que se pueden comprobar rápidamente:

• Latencias irregulares tras la implementación: O bien el TTL es demasiado largo en la rotación de enlaces simbólicos, o bien falta el «warm-up». Solución: TTL corto, reinicio de FPM y, a continuación, «priming».
• Muchas repetidas stat()-visitasCon strace visible; a menudo, el tamaño de la caché es demasiado pequeño o determinadas rutas dinámicas desplazan las entradas más solicitadas.
• Gran variabilidad entre los trabajadores: Caches diferentes por proceso. Solución: un calentamiento coherente y una distribución uniforme de las solicitudes.

A menudo basta con una rápida comprobación del estado mediante PHP:

<?php
$entries = realpath_cache_get();
$byDir = 0; $byFile = 0;
foreach ($entries as $e) { $e['is_dir'] ? $byDir++ : $byFile++; }
printf("Directorios: %d, Archivos: %d, Utilizado: %.2f MiB\n", $byDir, $byFile, realpath_cache_size()/1048576);

Así puedo ver si son sobre todo los directorios (muchos módulos, estructuras de proveedores) o los archivos (numerosas configuraciones y clases) los que predominan en la caché, y ajusto la estructura o el tamaño en consecuencia.

Caché de estadísticas frente a caché de rutas reales: una distinción deliberada

Además de la caché de Realpath, PHP también mantiene una Caché de estadísticas para los resultados de stat() y llamadas relacionadas. Ambas cachés se pueden gestionar con clearstatcache() influir en:

• clearstatcache() vacía la caché de estadísticas (opcionalmente para un archivo concreto).
• clearstatcache(true) Además, vacía la caché de Realpath.

En casos excepcionales —por ejemplo, con procesos CLI de larga duración con montajes dinámicos o en casos de intercambio en caliente—, utilizo un clearstatcache(true)-Hook tras los cambios conocidos. De lo contrario, dejo que el TTL haga su trabajo y evito invalidaciones innecesarias.

Comprobación práctica de entornos de alojamiento web

En primer lugar, calculo el tamaño del proyecto, es decir, cuántos archivos carga una solicitud típica, y después compruebo la carga del Cachés. A continuación, elijo un valor para `realpath_cache_size` que abarque todas las rutas de uso frecuente más un margen de reserva, y establezco un TTL que se adapte a los ritmos de implementación. Después, observo los efectos mediante herramientas de monitorización y registros, y ajusto los valores con cautela, en lugar de aumentarlos de forma drástica. Además, merece la pena echar un vistazo a la caché del sistema operativo, por ejemplo, a la configuración de Linux Presión de la caché VFS, porque Realpath se beneficia de búsquedas rápidas en los directorios. Así es como voy introduciendo mejoras sin pasar por alto los efectos secundarios.

Ámbito de aplicación y opciones de configuración: dónde establecer cada valor

Dependiendo del entorno, configuro los parámetros en distintos lugares:

• Global: php.ini para los valores predeterminados de todo el sistema.
• Pro-Pool: En los grupos de FPM por php_admin_value[realpath_cache_size] y php_admin_value[realpath_cache_ttl] dimensionar de forma específica para el front-end y la API.
• Directorio Pro: En .usuario.ini (si está permitido), lo cual resulta útil en entornos de alojamiento compartido.

Importante: los cambios en la php.ini Además, las configuraciones de FPM-Pool requieren un reinicio o una recarga para que los trabajadores se inicien con los nuevos valores.

CLI, Queue-Worker y tareas programadas: las mismas reglas, pero con tiempos de ejecución diferentes

Los scripts de la CLI y los trabajadores de cola también se benefician de la caché Realpath, aunque la Vida útil a menudo de otra manera:

• Tareas de la CLI de corta duración: La caché se recrea en cada llamada. En este caso, el «warm-up» y un TTL elevado sirven de poco; lo importante es que tenga un tamaño suficiente para que las inclusiones repetidas se almacenen en la propia caché del trabajo.
• Daemons/Worker: Los procesos de larga duración (Supervisor, Systemd) crean una caché estable. Tras un Recarga de código (Deploy) el proceso debería reiniciarse; de lo contrario, podrían quedar rutas obsoletas en la caché.

Evaluar la envergadura de los proyectos y el efecto de almacenamiento

Una aplicación con 4.000 rutas únicas y una longitud de ruta de 80 bytes, más 128 bytes de sobrecarga por entrada, ocupa aproximadamente 832 KB. Memoria en la caché de Realpath; como margen de seguridad, preveo 4 MiB o más. Si el código crece considerablemente debido a plugins o módulos, lo adapto de forma lineal y vuelvo a comprobar la Hits frente a los fallos. En los servidores compartidos, también tengo en cuenta los límites de inodos, ya que un número excesivo de archivos pequeños sobrecarga todo el sistema; para ello, me resulta útil este resumen que Límites de inodos. Es mejor contar con un margen de seguridad que ir siempre al límite. Así ahorro llamadas al sistema sin consumir RAM innecesariamente.

En pocas palabras: mi plan de tuning

Primero mido el número de archivos por solicitud y, a continuación, establezco un valor adecuado Tamaño de la caché y una que se adapte a la práctica de implementación TTL. A continuación, compruebo la carga con realpath_cache_get()/size(), la ajusto por etapas y combino todo ello con ajustes precisos en OPcache y la caché del sistema operativo. En las implementaciones de enlaces simbólicos, mantengo el TTL corto o reinicio FPM; en entornos estáticos, utilizo tiempos de vida largos. El objetivo sigue siendo una alta tasa de aciertos en la caché sin desperdiciar RAM. De este modo, aprovecho la caché de Realpath como un «turbo» subestimado para lograr un rendimiento constante de PHP.