Cómo medir correctamente la latencia en siete minutos

Para medir correctamente la latencia es necesario disponer de datos de calidad. El informe 2016 Global CEO Outlook de KPMG (enlace externo a ibm.com) reveló que el 84m % de los CEO están preocupados por la calidad de los datos en los que basan sus 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 (enlace externo a ibm.com) que las empresas que han adoptado un diseño basado en datos tienen un resultado entre un 5 % y un 6 % superior al que cabría esperar teniendo en cuenta sus otras inversiones y el uso de la tecnología de la información. 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 correctamente
• Errores comunes al examinar los datos de latencia
• La importancia del feedback instantáneo
• Por qué se necesitan datos sin muestrear

Dictionary.com (enlace externo a ibm.com) define la latencia como “el periodo de retraso en el que un componente de un sistema de hardware está esperando a 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, habría una latencia equivalente al tiempo que tardan los electrones del ordenador 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 suman rápidamente. La latencia no se define por unidades de trabajo y tiempo, sino por cómo se comporta. Las herramientas de monitorización informan del tiempo que transcurre desde el inicio de una función hasta su finalización.

La latencia puede tener un gran impacto en su negocio. Por ejemplo (enlace externo a ibm.com): “Cuando se trata de velocidad móvil, cada segundo importa: por cada segundo adicional que tarda una página móvil en cargarse, las conversiones pueden caer hasta un 20 %”.

La latencia casi nunca sigue una distribución gaussiana o Poisson normal. Incluso si su latencia sigue una de estas distribuciones, debido a la forma en que observamos la latencia, hace que las medias, las medianas e incluso las desviaciones estándar sean inútiles. Si, por ejemplo, está midiendo la carga 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 de este tema más adelante.

En este punto, probablemente se esté preguntando si no estamos utilizando 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 la gente piensa que al examinar el P95 se comprende el “caso común”. El problema con este método es que P95 va a ocultar todas las cosas malas. Como dice Gil Tene, CTO de Azul Systems: “Es un 'sistema de marketing'. Alguien está siendo engañado”.

Tomemos, por ejemplo, este gráfico:

Al observarlo, se puede ver claramente por qué su mediana y su media no tienen un significado real: no muestran el área problemática. Cuando se ve que el percentil 95 se dispara hacia la izquierda, se piensa que se está viendo el núcleo del problema. Sin embargo, eso no es cierto. Cuando investiga por qué su programa tuvo un problema, no ve el 5 % peor de lo que ocurrió. Para obtener este tipo de pico, es necesario 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 el espectro completo de sus datos.

Mucha gente puede pensar que el último 5 % de los datos no tiene tanta importancia. Claro, podría tratarse simplemente del reinicio de una máquina virtual (VM), un fallo en su sistema o algo por el estilo, pero al ignorarlo, está diciendo que eso no ocurre, cuando podría ser una de las cosas más importantes en las que centrarse.

A Gil Tene le gusta hacer la atrevida 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 lo máximo es, sin duda, una gran ventaja en un sistema a gran escala, a menudo no resulta práctico perseguir únicamente el caso máximo. Ningún sistema es perfecto y siempre surgen imprevistos. En un sistema práctico a gran escala, perseguir exclusivamente el caso máximo suele ser una buena forma 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 sus esfuerzos en estos pequeños contratiempos, lo hacen con un gran coste 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 el uno del otro, 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 se equivoca 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 buena señal de que lo que está viendo es un error real y no solo un pequeño contratiempo:

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

Tanto si se ha dado cuenta antes como si no, todos los percentiles de este gráfico están en la media. Así lo indica el eje x. Casi todos los servicios de monitorización promedian sus percentiles. Es una realidad debida al cálculo previo. Cuando su servicio de monitorización toma sus datos, calcula el percentil de los datos para ese minuto.

Luego, cuando mira el percentil 95, le muestra un promedio de todos sus percentiles. Este atajo para “su bien”, con el fin de agilizar su servicio, en realidad elimina toda la significación estadística de sus datos.

Lo sepa o no, al monitorizar las herramientas que participan en el muestreo de datos, estas producen datos promediados. Casi todas las herramientas de monitorización muestrean 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 los aceptará 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 máximo real, ni su percentil global es una representación precisa de lo que está sucediendo.

Cuando muestrea datos, está omitiendo datos. Supongamos, por ejemplo, que se realizan 10 000 operaciones en un minuto, enviando 2 puntos de datos cada uno a su sistema de monitorización. Supongamos 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 monitorización 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 durante el tiempo suficiente, el punto de datos aparecerá finalmente, 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 monitorización le engañe haciéndole creer que sabe lo que ocurre 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 análisis avanzados y machine learning (ML) para detectar automáticamente los problemas de latencia en tiempo real, lo que permite a los desarrolladores y equipos de TI identificar rápidamente la causa raíz 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.