Más allá del P95: midiendo la latencia que realmente experimentan sus usuarios
Un P95 saludable puede encontrarse junto a un producto lento. Cómo el tiempo de cola y la dispersión se ocultan de los paneles de control, y cómo la observabilidad paso a paso pone fin a las acusaciones por latencia.
Fuentes: Your P95 Latency Is Lying to You.
Un cliente informa que el producto parece lento. Alguien abre el panel de control de latencia y todo muestra un color verde: el P95 está dentro del rango deseado, la tasa de errores es estable, el uso de la CPU es bajo y las conexiones a la base de datos están muy por debajo del límite establecido. La conclusión tentadora es que la queja debe ser incorrecta, y ese instinto de confiar en un gráfico en lugar de en una persona que simplemente esperó es el verdadero problema.
Las secciones siguientes explican por qué un P95 aceptable y un producto lento pueden ser ciertos al mismo tiempo. Verá dónde se oculta la latencia detrás de las métricas de nivel de servicio (colas, intentos repetidos, distribución de solicitudes, decisiones que causan bloqueos), por qué la parte final de la distribución es más importante de lo que sugiere su tamaño, y cómo el simple hábito de medir cada paso de una solicitud por nombre convierte las quejas vagas en pruebas concretas. Al final, debería poder cuestionar de manera constructiva la afirmación de que “el P95 está bien”, en lugar de aceptarla o descartarla sin más.
Qué te dice y qué no te dice el P95
Valdría la pena ser preciso antes de criticar esta métrica. El P95 es el valor en o por debajo del cual se completan el 95 por ciento de las solicitudes medidas. Se trata de un número realmente útil, y representa una mejora significativa en comparación con la latencia promedio. La media es donde desaparecen los problemas en entornos de producción: si noventa y nueve solicitudes se completan en 50 ms y una tarda cinco segundos, la media es aproximadamente de 100 ms, un número que nadie usaría para tomar decisiones. Un percentil, al menos, dirige tu atención hacia los extremos de la distribución.
Así que el percentil en sí no es el problema. El problema radica en el papel que los equipos le dan después de leerlo. Frases como “El P95 está bien” suelen funcionar como un certificado de inocencia que pone fin a la discusión. Ese enfoque olvida silenciosamente algo fundamental: nadie que use tu producto experimenta un percentil. La gente experimenta tiempos de espera; presionan un botón y se preguntan si la acción se registró. Ven una página que parece estar cargada pero que no responde. Observan un indicador de carga mientras varios servicios detrás de ella muestran cifras perfectamente razonables.
Una API puede tener un excelente P95, mientras que el producto construido sobre ella se siente lento. Tener en cuenta ambos factores al mismo tiempo es el punto de partida para todo lo que sigue.
Tres “relojes” funcionan durante cada solicitud
La mayoría de las conversaciones sobre latencia asumen la existencia de un único reloj. En la práctica, hay al menos tres, y cada uno mide cosas diferentes.
- El reloj del servidor. Llega una solicitud a su servicio, se envía una respuesta y el temporizador se detiene. Esto es lo que muestran la mayoría de los paneles de control backend.
- El reloj de las dependencias. Dentro y alrededor de esa solicitud, el tiempo se destina a la autenticación, la espera por una conexión a base de datos compartida, llamadas HTTP internas, fallos en el caché, intentos repetidos, colas, búsquedas de indicadores de funcionalidad, APIs de terceros y todos los componentes que “normalmente son rápidos”.
- El reloj humano. El usuario hizo clic, luego esperó y finalmente la pantalla se volvió utilizable. Este es el único intervalo que le interesa al usuario.
Los equipos tienden a optimizar el primer registro de tiempo y luego describen el producto como rápido. El diagrama a continuación muestra los tres uno al lado del otro: el servicio indica 180 ms, mientras que la cadena de dependencias incluye un intento de reintentar con 600 ms y la persona que está frente al teclado sigue preguntándose por qué se está cargando la página.
SERVER CLOCK
request in ------------------------------> response out
"API P95: 180ms"
DEPENDENCY CLOCK
request in ---> auth ---> db ---> service A ---> retry ---> service B ---> response out
40ms 70ms 120ms 600ms 90ms
HUMAN CLOCK
click ----------------------------------------------------------------> usable screen
"Why is this still loading?"
Nada en el registro de tiempo del servidor está incorrecto. Simplemente es incompleto. Juzgar la velocidad del producto basándose en él es como tomarle la temperatura a alguien y declarar que todos sus órganos están sanos: ocasionalmente esa única lectura es exactamente lo que importa, y otras veces pasa por alto la enfermedad real.
Un endpoint es una puerta, un viaje del usuario es un edificio
Un modelo mental útil: un endpoint de backend es una sola puerta, mientras que el viaje del usuario es un recorrido por todo un edificio. Los paneles de control suelen medir las puertas. Una solicitud entra, una respuesta sale, el gráfico se actualiza y todos se relajan.
No obstante, los usuarios no están allí para admirar una puerta. Quieren llegar a un destino: abrir la pantalla principal, realizar un pago, hacer un pedido, descargar un estado de cuenta, completar una tarea real sin sentir que el producto duda al interactuar con ellos. Esa tarea rara vez corresponde a una sola llamada al sistema en segundo plano. Abrir un panel de control en una aplicación típica de página única se asemeja más al proceso desplegado a continuación, donde la interfaz solicita información sobre el perfil, permisos, cuentas, ofertas, notificaciones y límites antes de que aparezca algo útil.
User Clicks "Open Dashboard"
|
v
+----------------------+
| Frontend Shell |
+----------------------+
|
+------> GET /profile
|
+------> GET /permissions
|
+------> GET /accounts
|
+------> GET /offers
|
+------> GET /notifications
|
+------> GET /limits
|
v
Screen Finally Becomes Useful
Cada uno de esos seis puntos finales puede parecer funcional por separado, mientras que el proceso en su conjunto resulta defectuoso. Un servicio puede cumplir con sus acuerdos de nivel de servicio y, aun así, formar parte de un producto lento. Un equipo puede alcanzar sus propios objetivos y, no obstante, contribuir a una mala experiencia del usuario. Cuando las llamadas se realizan de forma secuencial, sus latencias se suman; cuando se ejecutan en paralelo, la más lenta determina el ritmo, y los límites de conexión por origen del navegador o una dependencia entre llamadas pueden serializar tareas que se suponía eran concurrentes.
Por eso, afirmar que “nuestra API es rápida” es el inicio de una investigación, no la respuesta. Las preguntas posteriores son incómodas pero necesarias: ¿rápida en comparación con qué, rápida para quién y rápidamente medida desde dónde? ¿Dentro de los límites de su servicio o desde el momento en que el usuario hizo clic?
El cinco por ciento restante no es un error de redondeo
El nombre “P95” hace que la parte negativa parezca insignificante. El cinco por ciento se percibe como un costo aceptable al operar a gran escala, algo que un comité de dirección tranquilo puede asumir.
Pero hay que considerar el volumen real. Un sistema que atiende un millón de solicitudes al día con umbral P95 tiene cincuenta mil solicitudes por encima de ese límite cada día. Cada una representa un momento en el que alguien podría hacer clic nuevamente, actualizar la página o abandonar el proceso y culpar al producto.
Incluso esta forma de presentarlo es demasiado simplista, porque las solicitudes lentas no se distribuyen de manera uniforme entre los usuarios:
- Un usuario desafortunado puede encontrarse repetidamente en el camino lento.
- Un único cliente empresarial puede quedar atado a un shard sobrecargado.
- Una región puede experimentar degradación mientras el promedio global sigue siendo aceptable.
- Un flujo de trabajo de alto valor puede ser lento, mientras que llamadas económicas y frecuentes mantienen el percentil en buenos niveles.
El panel de control muestra una distribución. El usuario afectado experimenta algo personal. Desde la perspectiva del sistema, una fracción de las solicitudes fue lenta; desde la perspectiva del usuario, el producto le hizo perder tiempo específicamente.
Por eso las quejas de los usuarios merecen ser consideradas como datos. La gente no informa en percentiles, sino a través de historias: “Se queda atascado cada vez que presiono enviar”. “La página aparece, pero los números llegan tarde”. “Tengo que volver a cargarlo dos veces”. “Funciona, pero parece lento”. Ninguna de estas descripciones es vaga; cada una es un informe de rendimiento escrito en lenguaje sencillo, y el error común es traducirlo a la métrica incorrecta y concluir que no hay ningún problema.
Dos servicios, un P95, riesgo muy diferente
Un único percentil no dice nada sobre la forma de la distribución alrededor de él. Considere dos servicios con un P95 similar. El primero es normal: la mayoría de las solicitudes son moderadas, las lentas solo lo son un poco más, y no hay picos bruscos. El segundo es rápido la mayor parte del tiempo, pero ocasionalmente cae en rangos de varios segundos.
SERVICE A
Most Requests 120ms - 260ms
Slow Requests 300ms - 380ms
Disaster Requests Rare
SERVICE B
Most Requests 40ms - 80ms
Slow Requests 300ms
Disaster Requests 8s - 12s
Ambos pueden reportar aproximadamente el mismo P95. Solo el Servicio B tiene un problema oculto, ya que se encuentra completamente más allá del percentil 95, donde ese valor no puede detectarlo. Al observar el P99, el P99.9 y el valor máximo, o mejor aún un histograma de latencia o un mapa de calor, es cuando se revela esa diferencia.
Un percentil también oculta dónde está concentrado el problema. No le indicará si las solicitudes lentas pertenecen a un arrendatario, un punto de extremo, una partición de base de datos, una dependencia posterior, una región, un camino de reintentos, un pool de hilos saturado o a una función que solo se utiliza durante demostraciones importantes. Desglosar la latencia según esas dimensiones es lo que convierte un número en un diagnóstico.
La regla práctica: un panel de control con percentiles debe iniciar una conversación, nunca cerrarla. La pregunta no es solo “¿cuál es nuestro P95?”, sino “¿qué tipo de problema se esconde detrás de este número?”
La peor latencia surge entre los equipos
Algunos problemas de latencia son casi fáciles de solucionar porque su causa es obvia. Una consulta lenta recibe un índice. Se añade cuidadosamente la caché que falta. Se reduce el tamaño excesivo de los datos transmitidos. Se reescribe un bucle ineficiente. Todos entienden estos casos.
Los problemáticos ocurren en las grietas entre los equipos. El backend informa que la API está funcionando bien. El frontend indica que está esperando al backend. La plataforma afirma que la pasarela está en orden. El equipo de base de datos comunica que la base de datos también está bien. El producto señala que los usuarios siguen insatisfechos. Cada uno de ellos dice la verdad, y eso es precisamente lo que hace tan frustrante la situación.
En estos casos el sistema no es lento en ningún lugar evidente. Es lento en las conexiones entre componentes:
- en la transferencia de datos entre servicios;
- en un intento de reintentar que duplica la duración de la llamada;
- en una segunda solicitud que nunca debería haberse realizado;
P95 no engañó a nadie al ser falso. Engañó al estar solo. Una métrica aislada permite que cada equipo demuestre su inocencia mientras el usuario sigue esperando.
El tiempo pasado en una cola sigue siendo latencia
Existe un problema de medición más sutil: los temporizadores a nivel de aplicación suelen iniciarse demasiado tarde. Para cuando tu manejador o controlador comienza a ejecutarse, la solicitud ya puede haber estado esperando en el balanceador de carga, aguardando una conexión, esperando a un trabajador o hilo, o quedándose atrás debido a otras tareas, ya que el proceso estaba técnicamente activo pero en realidad saturado. En Node.js, el mismo efecto se manifiesta como retraso en el bucle de eventos: un bucle ocupado significa que las devoluciones, incluido tu manejador de solicitudes, comienzan más tarde de lo que el socket recibió los datos.
Luego se inicia tu temporizador, tu código se ejecuta rápidamente y tus métricas registran una solicitud rápida. Al usuario no le importa dónde estuvo el límite de tu cronómetro; la espera antes de que comenzara el temporizador también cuenta. Lo mismo ocurre con las esperas durante los intentos de reintento, la espera a que el navegador realice la siguiente llamada necesaria y la espera a que un botón desactivado vuelva a ser clickeable.
Este es el problema de los límites de medición. Los equipos miden lo que su servicio puede observar y luego tratan implícitamente como inexistente todo lo que está fuera de ese rango de visión. La latencia que no se puede ver no es imaginaria; es una latencia de la cual nadie se hace responsable, y esa latencia sin dueño suele ser la más costosa, ya que nadie tiene la obligación de reducirla. Los tiempos de solicitud del balanceador de carga, las métricas de espera en el pool de conexiones, el retraso en el bucle de eventos y los tiempos del lado del navegador son las formas habituales de volver a visibilizar esos intervalos.
Asignar un nombre a cada paso de la solicitud
Lo que suele resolver estos conflictos no es otro panel de control, un proveedor nuevo o un presupuesto mayor para la observabilidad. Se trata de hacer que la parte lenta sea imposible de ocultar al dar a cada componente de la solicitud un nombre claro y preciso.
El fragmento a continuación es un manejador de Spring Boot en Java, pero este patrón se puede aplicar directamente en Express, Fastify o NestJS. Se inicia un LatencyTrace para la solicitud GET /home y se relaciona con el encabezado X-Request-Id recibido. Cada paso importante, como cargar al usuario, obtener permisos, llamar a los servicios de cuentas y ofertas, y mapear la respuesta, se envuelve en trace.time(...) junto con una etiqueta descriptiva. En el bloque finally, trace.logIfTotalCrosses(Duration.ofMillis(700)) emite el desglose solo cuando toda la solicitud supera los 700 ms, de modo que el registro permanece silencioso para tráfico normal y detallado para tráfico lento. La implementación exacta es menos importante que el hábito que fomenta.
@GetMapping("/home")
public HomeResponse home(@RequestHeader("X-Request-Id") String requestId) {
LatencyTrace trace = LatencyTrace.start("GET /home", requestId);
try {
User user = trace.time("db.user", () ->
userRepository.findActiveUser()
);
Permissions permissions = trace.time("auth.permissions", () ->
permissionClient.fetch(user.id())
);
List<Account> accounts = trace.time("accounts.http", () ->
accountClient.fetchAccounts(user.id())
);
List<Offer> offers = trace.time("offers.http", () ->
offerClient.fetchEligibleOffers(user.id())
);
return trace.time("response.mapping", () ->
HomeResponse.from(user, permissions, accounts, offers)
);
} finally {
trace.logIfTotalCrosses(Duration.ofMillis(700));
}
}
Hay dos detalles que merecen atención. Primero, finally garantiza que se registre la detección de errores incluso cuando uno de los pasos lanza una excepción, que es precisamente cuando más se necesita. Segundo, los pasos aquí se ejecutan uno tras otro, por lo que el tiempo total es aproximadamente la suma de ellos; si se paralelizan llamadas independientes como las relacionadas con cuentas y ofertas, el seguimiento aún debe medir el tiempo de cada una para poder ver cuál marca el ritmo.
Compare lo que le ofrece un registro de latencia ordinario con lo que produce este método. La versión habitual es una sola línea con un valor total:
GET /home took 1180ms
Es preciso, pero casi inútil, ya que no indica dónde se han empleado los 1,180 ms. La versión por niveles de paso responde a eso de inmediato:
GET /home took 1180ms
db.user 42ms
auth.permissions 81ms
accounts.http 156ms
offers.http 823ms
response.mapping 28ms
Con esa salida frente al grupo, el tono de la discusión cambia. Nadie necesita adivinar ni defender su propio servicio, y “funciona en mi lado” deja de ser una contribución significativa. Las ofertas representan aproximadamente el 70 por ciento de las solicitudes, por lo que la conversación pasa de las opiniones a las pruebas. Ese es el verdadero beneficio de una buena instrumentación: no más gráficos, sino menos argumentos.
En un códigobase de Node.js se puede lograr el mismo efecto con performance.now() alrededor de cada llamada pendiente y un registrador estructurado, o de manera más sistemática con spans de OpenTelemetry, los cuales mantienen los mismos nombres de paso más allá de las fronteras entre servicios, de modo que el desglose sigue siendo válido incluso cuando el paso lento se encuentra en el servicio de otra persona. Para un análisis más amplio sobre la combinación de registros, métricas y trazas, consulte construyendo APIs observables en Node.js.
Por qué las pruebas de rendimiento limpias pueden resolver un sistema desordenado
Este es el punto en el que un informe de rendimiento normalmente presentaría una tabla de pruebas. Hay una buena razón para no hacerlo aquí. Las pruebas de rendimiento son valiosas cuando son honestas, pero una inventada para este problema sería simplemente otro número engañoso disfrazado de datos formales.
El problema no es que los ingenieros no puedan realizar pruebas controladas. Es que las pruebas controladas tienden a eliminar justo ese caos que perjudica a los usuarios:
- Un benchmark prueba un único punto de extremo; una acción real del usuario activa muchos.
- Un benchmark se ejecuta con cachés ya cargados; los usuarios aparecen después de despliegues, eliminaciones y rutas de código sin caché.
- Un benchmark mide respuestas exitosas; los usuarios tienen que lidiar con fallos parciales, reintentos, tiempos de espera y pantallas desactivadas.
- Un benchmark asume dependencias estables; las dependencias en producción funcionan bien hasta el día en que dejan de hacerlo.
- Un benchmark aísla un servicio; lo que interactúan los usuarios está formado por varios servicios además de navegadores, redes, colas, contratos API y decisiones tomadas por equipos que ya pueden no comunicarse entre sí.
Un punto de referencia describe qué tan rápido puede ser un camino controlado. La producción describe cuán fiable es todo el sistema. Se trata de mediciones diferentes, y una no sustituye a la otra.
Un código rápido no garantiza un producto rápido
Muchos ingenieros de backend encuentran profundamente satisfactoria la optimización local. Logras reducir el tiempo de ejecución de una función de 20 ms a 8 ms, eliminas una asignación, reestructuras un bucle, ajustas una consulta, y la diferencia parece significativa. Mientras tanto, el producto sigue esperando a un servicio remoto que tarda 900 ms en cada décima solicitud. La pantalla sigue tardando demasiado en volverse utilizable, el botón sigue congelándose, y los tickets de soporte siguen indicando “lento”.
Eso es pulir el latón mientras el suelo se derrumba. El trabajo local resulta atractivo porque está completamente bajo tu control. La latencia de principio a fin es más complicada, ya que mejorarla implica a otros equipos, contratos antiguos, elecciones de producto y una arquitectura que nadie quiere reexaminar. Sin embargo, los usuarios no premian la elegancia local; premian las acciones completadas. Una función rápida es buena, un endpoint rápido es mejor, y un proceso ágil es lo que realmente cuenta. Antes de optimizar cualquier componente en particular, ayuda confirmar que forme parte del camino crítico de un proceso que le importe a alguien.
Cuando la dependencia más lenta es una decisión
No todo problema de latencia es técnico. Algunos son decisiones que se han convertido en parte de la arquitectura:
- El frontend llama a seis APIs cuando una respuesta agregada sería suficiente.
La parte más lenta de un sistema suele ser una elección de producto que nunca se midió, una brecha en la responsabilidad por su gestión, o una reunión de hace tiempo cuyo resultado se convirtió en una latencia permanente. Muchos de estos problemas tienen soluciones bien conocidas, como utilizar un backend para el frontend que agregue las llamadas, cargar de forma diferida los widgets no esenciales, desplazar las operaciones de reintentos y el análisis fuera del camino crítico, y diseñar respuestas adaptadas a la pantalla. Sin embargo, cada solución requiere que alguien tenga autoridad para cambiar una decisión.
Por eso, el trabajo de mejora del rendimiento se vuelve político una vez que se han aplicado las soluciones fáciles. La latencia restante se convierte en una cuestión de responsabilidad: ¿quién tiene derecho a declarar obligatoria alguna dependencia? ¿Quién es responsable de todo el proceso? ¿A quién se le permite eliminar una llamada? ¿Quién es responsable cuando todos los servicios funcionan bien pero la experiencia sigue siendo mala? El P95 no puede responder a ninguna de estas preguntas, y nunca fue su intención hacerlo.
Los paneles verdes pueden hacer que los equipos tengan menos curiosidad
Una observación menos halagüeña: un panel verde puede hacer que un equipo deje de hacer preguntas. No siempre, pero lo suficiente como para ser relevante. Cuando un gráfico se vuelve rojo, todos investigan. Pero cuando el gráfico es verde y un usuario se queja, la conversación tiende a centrarse en justificar esa queja. Quizás su conexión era mala, quizás su navegador era lento, quizás fue un caso aislado, o el soporte técnico exageró la situación, o la interfaz hizo algo inusual, o el cliente hizo clic demasiado pronto, o la queja es emocional y no técnica.
Así es como los equipos pierden la confianza, no por falta de datos, sino al usarlos como excusa para no escuchar. El usuario no tiene tu panel; tiene tu producto. Si para él este parece lento, eso es una prueba. No es una prueba completa ni perfecta, pero sí lo es.
Una cultura de ingeniería saludable considera el gráfico como una prueba y al usuario como otra, con la producción como el escenario a investigar. Una cultura que trata los gráficos como verdad y a los usuarios como ruido es la que lanza productos lentos mientras cree que son rápidos.
Comience por lo que intentaba hacer el usuario
Las discusiones sobre rendimiento suelen organizarse en torno a componentes: qué servicio, qué punto final, qué consulta es lenta. Esas son buenas preguntas, pero rara vez son la mejor pregunta inicial. Una forma más adecuada de comenzar es: ¿qué intentaba lograr el usuario? Una vez que responda a eso, suele surgir automáticamente la medida adecuada:
- Para abrir un panel de control, mida el tiempo hasta que esté realmente listo para usarse.
- Para enviar un formulario, mida desde el envío hasta que aparezca la confirmación visible.
- Para descargar un informe, mida desde el clic hasta que el archivo esté disponible.
Esto parece obvio, pero muchos sistemas no están instrumentados de esta manera. Se miden a lo largo de los límites de los equipos porque esos límites son fáciles de instrumentar y generan paneles de control ordenados. Los flujos de trabajo son más difíciles de medir y producen resultados menos favorables, y precisamente esos resultados menos favorables son la fuente de las mejoras en el producto. En el lado del cliente, las API del navegador como las interfaces de Rendimiento y Tiempo de Usuario permiten marcar explícitamente “el usuario hizo clic” y “la pantalla es utilizable”, y correlacionar esas marcas con un ID de solicitud vincula el reloj humano a los registros del servidor. Si resulta que la parte lenta está en el procesamiento de la interfaz y no en la red, el artículo sobre diagnóstico del rendimiento de React más allá del tiempo de respuesta de la API aborda ese aspecto del problema.
Trate las métricas con escepticismo respetuoso
Nada de esto constituye un argumento para eliminar el P95 de sus paneles de control. Pertenece allí y es importante, pero simplemente no debe confiarse en él por sí solo. Un buen percentil debería despertar aún más curiosidad, orientándolo hacia las solicitudes que se encuentran más allá del umbral:
- ¿Quiénes forman exactamente ese cinco por ciento lento, y son siempre las mismas personas?
- ¿A qué flujos de usuario pertenecen esas solicitudes?
- ¿Hay alguna dependencia responsable de la mayor parte de los casos problemáticos?
- ¿Algún área geográfica específica presenta problemas mientras la visión general parece estar bien?
- ¿Algún cliente en particular sufre constantemente las peores consecuencias?
- ¿Las reintentos están convirtiendo silenciosamente los fallos en largas esperas?
- ¿Cuánto tiempo pasan las solicitudes en cola antes de que incluso comience el temporizador de la aplicación?
La relación adecuada con una métrica no es ni adoración ni rechazo; es una sospecha respetuosa. Una métrica es un testigo, y los testigos pueden omitir cosas importantes.
Puntos clave
El escenario peligroso no es una métrica que esté claramente equivocada; eso sería fácil de detectar. Es una métrica que afirma una pequeña verdad con tanta confianza que todos dejan de buscar la verdad más amplia. La próxima vez que alguien diga que el P95 está bien, no discuta el número; pregunte qué cosas ha excluido. ¿Incluyó el tiempo de espera en la cola, los intentos repetidos, el tiempo de espera del frontend, la llamada a un tercero, que el usuario haga clic nuevamente porque no parecía ocurrir nada, y el momento en que la pantalla realmente se volvió utilizable para realizar la tarea para la cual llegó el cliente?
- P95 supera los promedios, pero oculta la forma de la distribución, la gravedad de las extremas y quiénes se ven afectados; úsalo junto con percentiles más altos, histogramas y desgloses por inquilino o región.
- Distinga entre los relojes del servidor, las dependencias y los relojes humanos, y asegúrese de que haya alguien a cargo de cada uno.
- El recorrido del usuario suele dividirse en muchas llamadas; mida todo el proceso, no solo los puntos finales.
- Los temporizadores de las aplicaciones a menudo no tienen en cuenta el tiempo de espera en colas, las conexiones y los retrasos en el bucle de eventos; mida esos aspectos explícitamente.
- Medir cada paso específico de una solicitud y registrar los detalles cuando se supera un umbral sustituye las acusaciones por pruebas concretas.
- Parte de la latencia es resultado de decisiones relacionadas con el producto y su gestión, y para solucionarla se necesita a alguien con autoridad para cambiar esas decisiones.
- Trate las quejas de los usuarios como informes de rendimiento y los paneles de control como un solo testimonio entre varios.
Lecturas relacionadas
- Por qué los patrones regex de retroceso pueden hacer fallar en silencio su servidor — Aprenda cómo la coincidencia codiciosa y el retroceso catastrófico pueden convertir un regex aparentemente correcto en una interrupción del servicio que agota la CPU, y cómo detectar el riesgo.
- Anti-patrones de backend: 7 errores costosos y sus soluciones prácticas — Aprenda cómo detectar y corregir siete errores comunes en la ingeniería de backend, desde controladores sobrecargados hasta errores no manejados, antes de que causen problemas en el servicio.