Cómo medir correctamente la latencia en siete minutos

Medir correctamente la latencia requiere que tenga datos de calidad. Perspectiva Global de CEO de KPMG 2016 (el enlace está fuera de ibm.com) encontró que el 84% de los directores ejecutivos (CEOs) están preocupados por la calidad de los datos en los que basan las decisiones, y es porque los datos a menudo pueden ser engañosos.

La diferencia entre las empresas que se preocupan por sus datos y las que no lo hacen es enorme. Los investigadores del MIT descubrieron (el enlace está fuera de ibm.com) que las empresas que han adoptado un diseño basado en datos tienen resultados que son entre un 5% y un 6% mayor de lo que se esperaría dadas sus otras inversiones y el uso de tecnología. Esta sola razón hace que comprender la latencia sea crítico para el éxito empresarial.

En solo siete minutos, aprenderá todo lo que necesita saber sobre la medición de la latencia:

• Cómo medir la latencia
• Por qué es importante medirla adecuadamente
• Errores comunes al mirar sus datos de latencia
• La importancia de la retroalimentación instantánea
• Por qué se requieren datos de muestra

Dictionary.com (el enlace está fuera de ibm.com) define la latencia como "el período de retraso en el que un componente de un sistema de hardware está esperando que otro componente ejecute una acción". En términos más simples, significa la cantidad de tiempo entre la llamada a una función y su ejecución real. La latencia es inherente a todos los sistemas; incluso si tuviéramos un sistema perfecto, que no existe, sería latente la cantidad de tiempo que tardan los electrones en la computadora en cambiar los transistores de encendido a apagado o viceversa.

La latencia en operaciones pequeñas no es un gran problema, pero cuando se manejan millones de operaciones, hay millones de latencias que se acumulan rápidamente. La latencia no se define por unidades de trabajo y tiempo, sino por cómo se comporta. Las herramientas de monitoreo informan cuánto tiempo pasa desde el inicio de una función hasta el final de la función.

La latencia puede tener un gran impacto en su negocio. Por ejemplo (el enlace está fuera de ibm.com): "Cuando se trata de la velocidad móvil, cada segundo importa—por cada segundo adicional que tarda una página móvil en cargarse, las conversiones pueden disminuir hasta en un 20%".

La latencia casi nunca sigue una distribución gaussiana o de Poisson normal. Incluso si su latencia sigue una de estas distribuciones, debido a la forma en que observamos la latencia, hace que los promedios, las medianas e incluso las desviaciones estándar sean inútiles. Si, por ejemplo, está midiendo cargas de páginas, el 99.9999999999% de estas cargas puede ser peor que su mediana. Es parte de la razón por la que el muestreo aleatorio de su latencia provoca datos inexactos, pero hablaremos más sobre este tema más adelante.

En este punto, probablemente se esté preguntando si no estamos usando ninguna desviación estándar, ¿cómo podemos describir las latencias de manera significativa? La respuesta es que debemos fijarnos en los percentiles y los máximos. La mayoría de las personas piensan para sí mismas, está bien, así que miro P95 y entiendo el "caso común". El problema con este método es que P95 ocultará todas las cosas malas. Como dice Gil Tene, Director de Tecnología de Azul Systems: “Es un 'sistema de marketing'. Alguien está siendo engañado”.

Tomemos, por ejemplo, este gráfico:

Cuando ve este gráfico, puede ver claramente por qué su mediana y promedio no tienen un significado real—no muestran el área problemática. Cuando ve que el percentil 95 se dispara hacia la izquierda, piensa que estás viendo el corazón del problema. Aunque, por supuesto, no es cierto. Cuando investiga por qué su programa tuvo un problema, no ve el peor 5% de lo que sucedió. Para obtener este tipo de pico se requiere que el 5% superior de los datos sea significativamente peor.

Ahora mire el mismo gráfico que también muestra el percentil 99.99:

Esa línea roja es el percentil 95, mientras que la línea verde es el percentil 99.99. Como puede ver claramente, el percentil 95 solo muestra 2 de 22 de sus problemas y por qué debe analizar todo el espectro de sus datos.

Muchas personas pueden pensar que el último 5% de los datos no tiene tanta importancia. Claro, podría ser solo el reinicio de una máquina virtual (VM), un problema en su sistema o algo así, pero al ignorarlo, está diciendo que simplemente no sucede cuando podría ser una de las cosas más importantes para a su objetivo.

A Gil Tene le gusta hacer la audaz afirmación de que “El indicador número uno del que nunca debe deshacerse es el valor máximo. Eso no es ruido, es la señal. El resto es ruido”. Si bien el máximo es, de hecho, un gran único en un sistema a gran escala, a menudo no es práctico perseguir solo el caso máximo. Ningún sistema es perfecto y se producen contratiempos. En un sistema práctico a gran escala, perseguir exclusivamente el caso máximo suele ser una buena manera de agotar a su equipo de desarrollo.

Al observar el percentil 99.99, está viendo lo que le sucede a la gran mayoría de sus clientes, y cualquier pico que vea allí sabe que es un problema real, mientras que cualquier pico en su máximo puede ser solo un problema en su sistema. Cuando sus equipos de DevOps centran su esfuerzo en estos pequeños contratiempos, lo hacen con un gran costo de oportunidad, ya que no pueden trabajar en problemas más importantes.

Cabe señalar que si su percentil 99.99 y su máximo están muy cerca entre sí—y ambos tienen picos—entonces es una gran señal de que es un problema en el que su equipo debe trabajar. De esta manera, Gil tiene razón en que el máximo es una gran señal, pero está equivocado en que el resto de sus datos son solo ruido. Como puede ver en este gráfico, nuestro percentil 99.99 y el máximo de nuestro ejemplo anterior coinciden exactamente. Es una gran señal de que lo que está viendo es un error real y no solo un problema:

Un escollo aún peor en el que caen las personas que solo mirar el percentil 95 es no reconocer que sus percentiles están promediados. Promediar percentiles es estadísticamente absurdo; elimina todo significado de lo que está viendo. Ya hemos demostrado cómo los promedios no son buenos cuando se analiza la latencia y, si se analizan los percentiles promediados, simplemente se vuelve al punto de partida. Muchos programas de software promedian sus percentiles. Tomemos, por ejemplo, este gráfico de Grafana:

Ya sea que se haya dado cuenta antes o no, todos los percentiles en este gráfico son promedio. Lo dice en el libro mayor del eje x. Casi todos los servicios de monitoreo promedian sus percentiles. Es una realidad debido al precálculo. Cuando su servicio de monitoreo toma sus datos, calcula el percentil de los datos para ese minuto.

Luego, cuando observa su percentil 95, le muestra un promedio de todos sus percentiles. Este atajo para que “su bien” haga que su servicio sea más rápido es, en realidad, eliminar toda la importancia estadística de sus datos.

Lo sepa o no, al monitorear las herramientas que participan en el muestreo de datos, están produciendo datos promediados. Casi todas las herramientas de monitoreo toman muestras de sus datos. Tomemos, por ejemplo, Datadog—tiene una gran pérdida de datos. Si les envía 3 millones de puntos en un minuto, no se los llevará a todos. En su lugar, muestreará aleatoriamente los puntos y luego los agregará en 1 punto por minuto.

Debe tener datos sin muestrear para comprender su latencia. Es inherente que con los datos muestreados no se puede acceder a la distribución completa. Su máximo no es su verdadero máximo, ni su percentil global es una representación precisa de lo que está sucediendo.

Cuando muestrea datos, está omitiendo datos. Digamos, por ejemplo, que tiene 10,000 operaciones en un minuto, enviando 2 puntos de datos cada uno a su sistema de monitoreo. Digamos que tiene un error en su sistema y uno de estos puntos de datos muestra este error por cada 10,000 operaciones. Su sistema de monitoreo solo tiene una probabilidad de 1/20,000 de elegir este error como el punto de datos que le muestra como máximo.

Si se ejecuta el tiempo suficiente, el punto de datos aparecerá con el tiempo, pero, como resultado, parecerá un caso extremo esporádico, aunque le esté sucediendo a uno de sus clientes cada minuto. Cuando no muestrea datos y tiene uno de estos picos, aparecerá claramente en su percentil 99.99, y su máximo aparecerá cerca de él, lo que indica que tiene un error en su programa. Sin embargo, cuando muestree sus datos, no aparecerá con tanta frecuencia, lo que significa que no lo verá como un error sino como un contratiempo. Este resultado significa que su equipo de ingeniería no se dará cuenta de su importancia.

No deje que su herramienta de monitoreo lo engañe haciéndole creer que sabe lo que está pasando con su latencia. Una de las características clave del software IBM Instana™ es su capacidad para medir la latencia de manera eficiente. El software IBM Instana utiliza analytics avanzados y machine learning (ML) para detectar automáticamente problemas de latencia en tiempo real, lo que permite a los desarrolladores y equipos de TI identificar rápidamente la causa principal de cualquier problema de rendimiento y tomar medidas correctivas antes de que afecten a los usuarios.

Elija una herramienta que no proporcione datos de muestra. Elija una herramienta que no promedie sus percentiles globales.