Fallos de la caché de la CPU en el alojamiento: causa invisible del bajo rendimiento

Los fallos de caché de la CPU se producen cuando el procesador no puede encontrar datos en la caché y tiene que recuperarlos de la RAM, lo que aumenta la velocidad de la CPU. Latencia alto y estrangula el rendimiento del alojamiento. Te mostraré por qué estas caídas silenciosas suelen ser el verdadero freno de los sitios web dinámicos, cómo las mido y cómo tomo medidas claras para minimizarlas. rendimiento del alojamiento estable de nuevo.

Puntos centrales

Los siguientes aspectos enmarcan el artículo y ofrecen la visión más rápida.

• CausaLos accesos irregulares desplazan las líneas de caché y aumentan los accesos a la RAM.
• SíntomasTTFB creciente, picos a baja carga, alta espera de CPU.
• DiagnósticoContador de hardware, perfilador y correlación con métricas de E/S.
• MedidasPáginas, objetos y OPCache, índices de BD, ajuste CPU/NUMA.
• Valores objetivoTasa de fallos inferior a 5-10%, TTFB estable en el rango bajo de tres milisegundos.

¿Qué son las pérdidas de caché de la CPU en el contexto del alojamiento?

Las CPU de los servidores modernos funcionan con cachés multinivel que entregan los datos en unos pocos ciclos; un CacheSin embargo, -Miss obliga al núcleo a recargar la información desde niveles significativamente más lentos. Esto ocurre precisamente cuando el latencia de la cpu del servidor, porque el núcleo espera en lugar de calcular. En el alojamiento, el código dinámico como PHP y los accesos a bases de datos provocan una dispersión de la memoria, lo que significa que a menudo faltan líneas de caché. Normalmente, L1 reacciona con extrema rapidez, el salto a L2/L3 cuesta notablemente más y los accesos a RAM dominan el tiempo. Si quieres entender el comportamiento de Cachés L1-L3 reconoce inmediatamente por qué los fallos ralentizan notablemente un sitio web.

La siguiente tabla clasifica a grandes rasgos la intensidad de una pérdida y explica por qué siempre compruebo primero las tasas de pérdida. Muestra valores de ciclo típicos y ayuda a evaluar el efecto de una línea de caché perdida frente a un acierto rápido de caché. Me atengo a estimaciones conservadoras porque las cargas de trabajo reales fluctúan. Los tamaños sirven para categorizar, no como regla rígida. Sigue siendo importante: Cada excursión a la RAM aumenta el tiempo de respuesta y pone en peligro el rendimiento del alojamiento.

nivel de almacenamiento	Latencia típica (ciclos)	Tamaño típico	Clasificación con Miss
L1	1-4	32-64 KB por núcleo	Apenas se nota; ideal para Caliente-Datos
L2	~10-14	256-1024 KB por núcleo	Fácilmente perceptible; sigue siendo eficiente
L3 (nivel de carga)	~30-60	Varios MB compartidos	Notable; dependiendo de la contención
RAM	100-300	Área GB	Claramente; conduce TTFB alta

Por qué los errores aumentan la latencia del servidor

Cada acceso perdido recupera datos de niveles inferiores y cuesta tiempo; en total, estas fases de espera suman un retraso notable. Latencia. Si la tasa de fallos aumenta, el núcleo espera la memoria con más frecuencia y puede ejecutar menos lógica de aplicación. Veo esto regularmente en los picos de TTFB: las cachés rápidas entregan inmediatamente, los accesos a la RAM empujan la respuesta del primer byte al área roja. Se vuelve particularmente crítico con WordPress cuando los objetos PHP, las opciones y las filas SQL se distribuyen por todo el sistema. Es precisamente cuando el rendimiento del alojamiento a la baja, aunque la utilización de la CPU y la RAM parece seguir siendo moderada.

Las mediciones muestran un patrón claro: a partir de una tasa de fallos de alrededor de 5-10%, los tiempos de espera aumentan significativamente; a partir de valores de dos dígitos, los tiempos de solicitud a menudo se duplican. Esto sucede incluso si la máquina todavía tiene espacio para funcionar, porque los ciclos de espera bloquean el progreso. Por tanto, no sólo compruebo la utilización, sino sobre todo los índices de aciertos de la caché y los patrones de acceso a la memoria. Las respuestas de 50 ms TTFB pasan rápidamente a 600 ms y más si el código solicita datos muy dispersos. Optimizar en este caso significa girar el Tornillo principal rendimiento de la web.

También está el nivel de coherencia: varios núcleos comparten la L3 e invalidan las líneas de caché de los demás si se escriben en las mismas direcciones de memoria. Esto provoca retrasos adicionales y agrava los fallos. Por tanto, presto atención a los puntos calientes de escritura (como contadores globales, bloqueos de sesión) y reduzco el uso compartido incorrecto de líneas de caché cuando los procesos operan cerca unos de otros en estructuras compartidas. Menos tráfico de coherencia significa más Localidad e inferior Latencia.

Causas comunes en la pila de alojamiento

Los accesos irregulares desencadenan tormentas de fallos, especialmente durante los arranques en frío sin caché de páginas; entonces, cada petición recarga el código de bytes, los objetos y las conexiones. Los escaneos amplios de bases de datos sin índices destruyen el Localidad y arrastran enormes cantidades de datos a través del sistema. Los bucles PHP con muchas operaciones de cadena distribuyen los datos de trabajo, lo que significa que la caché encuentra menos aciertos. Las esperas de E/S debidas a la lentitud de los SSD o a los límites de los discos duros desplazan constantemente los hilos y desplazan las líneas de caché de las etapas pequeñas. En WordPress, las grandes opciones autocargadas y los hooks muy frecuentados - por ejemplo en las tiendas - ponen a prueba a la Cache-eficiencia.

Las pequeñas cosas suman: un plugin de depuración que ejecuta consultas extra duras en cada página desajusta las cachés L1/L2. Lo mismo se aplica a muchos PHP FPM workers simultáneos en muy pocos núcleos; el programador lanza hilos de un lado a otro, los datos de trabajo se enfrían. Los cambios de contexto aumentan la probabilidad de fallo porque el nuevo hilo necesita datos diferentes. La CPU no sólo tiene que recargar el código, sino también las estructuras relevantes. Son precisamente estos patrones los que impulsan el latencia de la cpu del servidor alta sin que la causa se manifieste inmediatamente.

A menudo veo otros antipatrones en el día a día: cambio de backends de sesión dependiendo de la petición, invalidación de cachés enteras con pequeños cambios de contenido y TTLs que son demasiado cortos y fuerzan al sistema a arranques en frío permanentes. Los trabajos cron por lotes que calientan o limpian todo al mismo tiempo durante la noche también lanzan el Cachés de nuevo. Son mejores las invalidaciones graduales, el jitter en los TTL y una separación clara entre las rutas de lectura y escritura, para que los hotsets permanezcan en memoria.

Diagnóstico en la práctica: de los contadores de hardware a los perfiladores

Empiezo con los contadores de hardware, porque muestran los fallos directamente: perf proporciona valores para cache-misses y cache-references, que comparo con el tiempo de ejecución. Para realizar análisis más detallados, utilizo herramientas PMU para analizar L1, L2 y L3 por separado, lo que me permite ver exactamente dónde está el problema. Paralelamente, monitorizo htop y pidstat para registrar los picos de espera de la CPU y los cambios de proceso. También utilizo perfiladores APM en pilas dinámicas, por ejemplo para identificar puntos calientes en funciones PHP o sentencias SQL. Esta combinación separa el ruido de la señal y apunta específicamente al cuello de botella allí.

Los datos de registro refuerzan la imagen: los registros de consultas lentas revelan escaneos amplios, iostat descubre esperas de E/S y longitudes de cola. Correlaciono las marcas de tiempo de los picos de TTFB con estos puntos de medición y compruebo si coinciden con fallos. Si se producen fallos en puntos finales concretos, aíslo el código afectado y vuelvo a medirlo con la misma carga. De este modo, puedo saber rápidamente si la base de datos, PHP, el sistema de archivos o el programador son los causantes del fallo. Cache-eficiencia. El objetivo sigue siendo claro: menos fallos, más aciertos, tiempos de respuesta más rápidos.

Para obtener resultados reproducibles, utilizo un libro de jugadas breve y mantengo constante la duración de la medición para que los valores atípicos no provoquen conclusiones falsas:

# 30 segundos de métricas de proceso (personalizar PID)
perf stat -e cycles,instructions,cache-references,cache-misses,branches,branch-misses -p $(pidof php-fpm) -- sleep 30

# Ver puntos calientes en directo
perf top -p $(pidof php-fpm)

# Registrar rutas y luego analizarlas
perf record -F 99 -g -p $(pidof php-fpm) -- sleep 20
perf report

# Cambio de proceso/hilo y espera de CPU
pidstat -wtud 1 60

También evalúo MPKI (fallos por cada 1.000 instrucciones) y CPI (ciclos por instrucción). Un MPKI de un solo dígito y un CPI cercano a 1 indican un buen rendimiento. Localidad . Si MPKI aumenta en dos dígitos, el TTFB suele estar inclinado; si CPI aumenta visiblemente, predominan los núcleos en espera de datos. Junto con TTFB, los tiempos de respuesta P95/P99 y la espera de la CPU, estos ratios constituyen la base sólida para tomar decisiones.

Límites específicos y síntomas típicos

Una tasa de fallos sostenida por encima de 10% indica problemas, los valores por debajo de esto son todavía manejables en mi opinión; la ventana varía dependiendo de la carga de trabajo. Una espera de CPU por encima de 20% con TTFB inflacionario simultáneo es un fuerte indicio de atascos de memoria. Picos de carga inexplicables con tráfico aparentemente tranquilo indican accesos ineficientes, a menudo provocados por consultas individuales o rutas PHP caras. Si el rendimiento se mantiene constante pero el tiempo de respuesta varía mucho, los anchos de distribución indican estados cambiantes de la caché. En esos momentos, compruebo específicamente el Srta.-métricas y hacerlas coincidir con las rutas del código.

El comportamiento después de un despliegue también proporciona pistas: Los procesos nuevos se ejecutan “en frío” hasta que se llenan la OPCache y la caché de objetos. Si el TTFB desciende de forma estable después de unos minutos, esto indica que las cachés están surtiendo efecto y que la localidad está aumentando. Si la latencia sigue siendo alta a pesar del estado caliente, busco SELECTs anchos o índices mal posicionados. También miro la configuración de PHP, como los ajustes de JIT y OPCache. Echar un vistazo más de cerca ahorra mucho aquí Tiempo y evita malas inversiones en hardware.

Medidas: Activar la caché de forma coherente en todos los niveles

Yo siempre empiezo con caché de páginas para usuarios anónimos, caché de objetos para estructuras de uso frecuente y OPCache para bytecode PHP. El trío reduce la ejecución de código y mantiene Caliente-datos en memoria rápida, lo que reduce la tasa de fallos. Redis o Memcached entregan rápidamente sin sobrecargar el búfer de la base de datos; unas claves de caché limpias garantizan el índice de aciertos. Si se añade una CDN, las cabeceras de control de la caché deben establecerse de forma limpia para que las etapas intermedias reutilicen el contenido de forma fiable. Esto reduce la carga de la lógica de backend y disminuye la TTFB incluso antes de realizar optimizaciones más profundas.

Establezco validaciones largas para activos estáticos y valores cortos de smaxage para HTML; ambos protegen la CPU de trabajo innecesario. Las configuraciones de Nginx pueden mantenerse claras y seguir siendo fáciles de auditar. El siguiente ejemplo muestra una base ajustada que adapto a las reglas del proyecto. Con cabeceras como esta, la tasa de aciertos de la caché aumenta significativamente en las etapas intermedias, mientras que la fuente se salva. Aquí es exactamente donde la ganancia notable en Actuación en alojamiento:

location ~* \.(html)$ {
  add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate";
}
location ~* \.(css|js|png|jpg)$ {
  add_header Cache-Control "public, immutable, max-age=31536000";
}

Calentamiento y protección contra estampidas tras los despliegues

Después de los despliegues, caliento específicamente las cachés: precarga de OPCache para archivos PHP centrales, un breve rastreo sintético de las rutas más importantes y llenado de claves de caché de objetos críticos. Establezco tiempos de smaxage cortos para HTML, de modo que las etapas intermedias aprendan rápidamente, como suele ocurrir. Al mismo tiempo, evito las estampidas de caché utilizando bloqueos con tiempos de espera y un patrón de „actualización temprana“: antes de que expire un TTL, un único trabajador recarga, mientras que los usuarios siguen viendo el último objeto válido. Un pequeño jitter en los TTL evita que muchas entradas se ejecuten al mismo tiempo y se inicien oleadas de misses.

El almacenamiento en caché negativo (TTLs cortos para resultados vacíos) reduce la presión sobre las rutas backend que a menudo sirven búsquedas fallidas o rutas 404. También merece la pena limitar la velocidad de las rutas caras hasta que se complete el calentamiento. Esto mantiene la rendimiento del alojamiento estable, incluso cuando se producen nuevos despliegues o picos de contenido.

Aliviar la base de datos y las consultas

Primero compruebo los índices de las columnas WHERE y JOIN, porque los índices que faltan fuerzan los escaneos amplios y destruyen el Localidad. A continuación, simplifico las consultas, divido los SELECT grandes y evito las columnas innecesarias; cada byte menos estabiliza la huella de la caché. Para obtener resultados recurrentes, utilizo la caché de aplicaciones, como transients o claves de caché de objetos dedicadas con invalidación clara. Con WordPress en particular, ahorro mucho tiempo cuando las costosas opciones y metaconsultas desaparecen de la ruta caliente. Cada reducción de la cantidad de datos y de la dispersión disminuye el Srta.-probabilidad notable.

Los parámetros de la BD también deben ser adecuados: Los búferes grandes por sí solos no resuelven el problema si los accesos siguen sin estar dirigidos. Presto atención a una buena relación entre el tamaño del búfer, el número de conexiones y la combinación de consultas. Separo las consultas de larga duración de las rutas interactivas para evitar la congestión. A continuación, observo el efecto sobre el TTFB y la tasa de fallos de forma combinada, no aislada. Este acoplamiento muestra si los datos están realmente más cerca de la CPU Muévete.

También son útiles los índices de cobertura que abarcan todas las columnas necesarias de una consulta frecuente, ya que permiten al motor ofrecer resultados directamente desde el índice sin acceso adicional a los datos. Con los índices compuestos, observo la secuencia de columnas a lo largo de los predicados selectivos. Reduzco la carga de las grandes ordenaciones y tablas temporales utilizando estrategias LIMIT/Seek adecuadas y evitando los ORDER BY innecesarios en las rutas calientes. Cuantos menos movimientos de página haya en el buffer pool, más estable será el Localidad.

Configurar PHP y OPCache correctamente

Un OPCache activado con límites razonables reduce los accesos a archivos y estabiliza el Caliente-paths en la caché. Pongo opcache.enable=1 y compruebo el tamaño de la memoria para que quepan todos los scripts productivos. Con opcache.jit=tracing reduzco el tiempo de ejecución y los misses indirectos, porque se interpreta menos y se compila más. En la práctica, estas medidas eliminan tiempos de espera notables, especialmente para endpoints de computación pesada. La comprobación posterior de la validación del bytecode evita errores innecesarios. Frío-comienza a lo largo del día.

También merece la pena echar un vistazo a las operaciones de cadenas y matrices que generan grandes copias; aquí ahorro memoria y presión de caché mediante refactorizaciones selectivas. Mido cada cambio con una carga idéntica para ver claramente el efecto. Si la tasa de fallos cae paralelamente al tiempo de ejecución, confirmo el camino. Si la tasa sigue siendo alta, busco más a fondo la dispersión en las estructuras de datos. Este ciclo de medición, ajuste y verificación produce resultados reproducibles. éxitos.

Además, estabilizo las búsquedas de archivos y el autoloader: Un realpath_cache_size suficientemente grande y un realpath_cache_ttl conservador reducen las costosas operaciones de stat. Las optimizaciones de Composer (classmaps clasificados) acortan la ruta de búsqueda del autoloader. Yo mantengo opcache.validate_timestamps bajo en producción o lo desactivo cuando los pipelines de despliegue se invalidan limpiamente - esto mantiene los bytecodes constantes, y el Cache-las líneas de las vías calientes se enfrían con menos frecuencia.

Configuración del servidor: utilizar la afinidad de CPU de forma selectiva

Al anclar los procesos a núcleos fijos, los datos de trabajo se mantienen calientes porque menos cambios de contexto desplazan las líneas de caché. Los pools de PHP FPM, los trabajadores de Nginx y los procesos de base de datos se benefician si los distribuyo de forma planificada. Empiezo con unos pocos trabajadores bien utilizados por núcleo y sólo los amplío si es necesario. A continuación, controlo la tasa de errores y TTFB para encontrar el equilibrio entre el paralelismo y la utilización. Cache-hits. Encontrará información detallada en el artículo sobre Afinidad CPU, que utilizo para el ajuste fino.

Los parámetros del kernel, como las funciones sched y la distribución de IRQ, también influyen en la consistencia con la que los núcleos soportan la carga. Suelto las IRQ netas de los hotpaths cuando interfieren con las cachés y vigilo los dominios NUMA. De este modo, reduzco las interferencias que caen sobre L1/L2 y mantengo L3 libre de cargas extrañas. Al final, lo que cuenta es la repetibilidad, no el valor máximo en los benchmarks. Aquí es exactamente donde la sostenibilidad Ganancias para sistemas productivos.

Contenedores, virtualización y „vecinos ruidosos“

En contenedores o máquinas virtuales, el hipervisor mueve hilos entre pCPUs; sin pinning, los procesos pierden su Cache-proximidad. Utilizo cpuset/cgroups para colocar a los trabajadores de forma estable en los núcleos y minimizar el overcommit. Los „vecinos ruidosos“ de la misma máquina desplazan el contenido L3: unos límites de recursos claros y zonas NUMA separadas amortiguan estos efectos. En pilas mixtas (web, PHP, base de datos), separo los servicios ruidosos de los críticos para la latencia, de modo que los hotsets no se enfríen constantemente. Hyper-threading ayuda con el rendimiento, pero puede aumentar la varianza si hay mucho stall de memoria; mido ambos modos y tomo una decisión basada en datos.

NUMA: control consciente de los nodos de almacenamiento

Los servidores multisocket dividen la memoria en nodos; si un proceso accede a memoria “ajena”, aumentan las latencias y los riesgos de uso indebido. Vinculo los servicios a los núcleos y los enlazo a la memoria asociada para que la ruta siga siendo corta. Las grandes memorias caché en memoria se benefician de ello, sobre todo porque se almacenan siempre en un nodo de la red. Cache permanecen. También controlo los fallos del TLB y, si es necesario, utilizo Huge Pages para aliviar las tablas de páginas. La guía de Equilibrio NUMA, lo que facilita el ajuste fino.

Reconozco desajustes por altos accesos remotos y cargas L3 cambiantes entre sockets. Una secuencia de inicio limpia de los servicios y una mirada cercana a los cgroups ayuda aquí. Mantengo procesos estrechamente relacionados (web, PHP, DB proxy) en el mismo dominio. Luego vuelvo a medir y comparar la tasa de fallos, la espera de la CPU y el TTFB a lo largo del tiempo. Este orden en la subestructura se ve recompensado por la estabilidad. Actuación de.

Casos prácticos de WordPress

En las tiendas, a menudo observo enormes opciones autocargadas que se cargan con cada petición; reduzco estos valores y almaceno los datos raramente utilizados en la caché de objetos. También veo costosos hooks de WooCommerce que se ejecutan en cada petición de página y cargan los Cache dispersar. Minimizo estos puntos utilizando condiciones específicas para cada objetivo, de modo que sólo se disparen las rutas relevantes. Con la API Heartbeat, limito las frecuencias innecesarias para evitar el tráfico ocioso y las cadenas erróneas. A continuación, establezco ventanas de caché HTML cortas para que el tráfico anónimo toque las rutas del backend con menos frecuencia y el TTFB permanece estable.

Las imágenes y los scripts también influyen en la situación general: cuantos menos recursos críticos haya en la primera vista, menos trabajo de competencia habrá en el servidor. Priorizo las rutas de renderizado, no uso HTTP/2 Push innecesariamente y prefiero confiar en cabeceras de caché inteligentes. De este modo, mantengo el backend y el frontend en armonía en lugar de crear el caos mediante una entrega excesivamente motivada. Cada simplificación despeja los accesos a la memoria y refuerza la localidad. Esto reduce la tasa de fallos y el Respuesta-sigue el tiempo.

En la práctica, establezco grupos de borrado para las cachés de objetos persistentes y sólo invalido los subconjuntos afectados, no la totalidad. Muevo los transitorios a la caché de objetos para ahorrar accesos a ficheros PHP. Cargo los widgets basados en consultas de forma asíncrona o los almaceno en caché por separado para que el primer byte no espere a las rutas lentas de la base de datos. Remuevo herramientas que recolectan datos de depuración en producción de la ruta caliente - una bandera de característica por ambiente previene que las mediciones sean involuntariamente Cache-ruina el golpe.

Ejemplo práctico: de inquieto a estable

Un caso típico: tasa de fallos de caché de 12%, TTFB fluctúa entre 120 ms y 900 ms bajo carga moderada. Tras el análisis, encuentro amplias consultas de listas de productos sin índices adecuados, un plugin de depuración en la ruta caliente y 32 trabajadores PHP FPM en 8 núcleos. Medidas en secuencia: eliminación del plugin de depuración, índices añadidos a WHERE/JOIN, caché de páginas con smaxage de 5 minutos, claves de caché de objetos introducidas para teasers de productos, trabajadores FPM reducidos a 12 y anclados mediante afinidad. Resultado tras una nueva prueba de carga: Miss rate 4-6%, CPI drops, TTFB stabilises at 140-220 ms, outliers disappear. Esto también demuestra que el Tornillo principal fue golpeado correctamente.

Plan de seguimiento y cifras clave que realmente cuentan

Realizo un seguimiento permanente de la tasa de errores, las referencias de caché y la espera de la CPU para que los valores atípicos sean inmediatamente reconocibles. Al mismo tiempo, mido el TTFB, el tiempo hasta la interactividad y la frecuencia de respuesta de la aplicación para visualizar los efectos en los usuarios. Las cabeceras de respuesta, como las tasas Age y 304, me muestran lo bien que se están almacenando en caché las etapas intermedias y el Origen aliviar la carga. Mido cada ajuste antes y después de la puesta en marcha bajo una carga idéntica para que los efectos estacionales no nublen la vista. Solo cuando la tasa de fallos, la latencia y las métricas de usuario descienden a la vez, el cambio es realmente efectivo. eficaz.

Establezco límites: tasa de fallos idealmente por debajo de 5-10%, TTFB para páginas dinámicas estable en el rango de milisegundos de tres dígitos bajos, espera de CPU en el rango porcentual de un dígito. A continuación, defino alarmas que se activan pronto en caso de desviaciones. Los trabajos nocturnos, en particular, no deben descartar las cachés para el tráfico diurno; las separo y mido el efecto. De este modo, el rendimiento se mantiene constante y previsible. Precisamente este compromiso hace que la optimización sea medible y Escalable.

También controlo MPKI, CPI y las tasas de fallo de rama porque explican el lado micro cuando las métricas de aplicación se vuelven llamativas. Para MPKI, mi objetivo son los valores bajos de un solo dígito; cualquier cosa por encima de eso llama mi atención. Para el CPI, mi objetivo es cercano a 1; si el valor aumenta significativamente, suele haber algún problema con la ruta de memoria. Combino estos objetivos con SLO (por ejemplo, P95 TTFB) y vinculo alarmas para que no se activen por cada pequeño pico, sino por desviaciones repetidas. La estabilidad supera los valores máximos.

Resumen: Cómo hacer que el servidor vuelva a ser rápido

Los fallos de la caché de la CPU cuestan tiempo porque los núcleos están esperando la memoria; yo los combato con una caché coherente, una arquitectura de base de datos limpia y un ajuste específico del sistema. El orden cuenta: en primer lugar, establezco una caché de páginas, objetos y OPC estable; a continuación, ajusto las consultas y desentraño los hotpaths. A continuación, ajusto Affinity y NUMA para que los datos permanezcan cerca de los núcleos y las Localidad aumenta. La supervisión continua confirma el efecto y evita recaídas debidas a despliegues o cambios de plugins. Si sigue estos pasos, reducirá notablemente las latencias, estabilizará el rendimiento del alojamiento y crea reservas para el tráfico real.

Permítanme resumir: Reducir el porcentaje de fallos, aumentar el porcentaje de aciertos, suavizar el TTFB... así es como mantengo el control. Las herramientas proporcionan valores medidos, pero sólo las decisiones arquitectónicas claras garantizan resultados duraderos. Cada optimización tiene como objetivo mantener el trabajo en la caché rápida y evitar costosos viajes a la RAM. Este enfoque permite planificar el rendimiento y utilizar el presupuesto de forma inteligente. Así es exactamente como desaparecen los frenos invisibles y el servidor vuelve a ser rápido.