Comment mesurer correctement la latence en sept minutes

Équipe de personnes créatives travaillant dans un bureau moderne

Pour mesurer correctement la latence, vous devez disposer de données de qualité. L'étude de KPMG de 2016 Global CEO Outlook (lien externe à ibm.com) a révélé que 84 % des PDG sont préoccupés par la qualité des données sur lesquelles ils basent leurs décisions, principalement parce que les données peuvent souvent être trompeuses.

Il existe une énorme différence entre les entreprises qui se soucient de leurs données et celles qui ne le font pas. Les chercheurs du MIT (lien externe à ibm.com) ont constaté que les entreprises qui avaient adopté une conception fondée sur les données obtenaient des résultats 5 à 6 % supérieurs à ceux attendus compte tenu de leurs autres investissements et de l’utilisation des technologies de l’information. Cette seule raison rend la compréhension de la latence critique à la réussite de l’entreprise.

En seulement sept minutes, vous apprendrez tout ce que vous devez savoir sur la mesure de la latence :

  • Comment mesurer la latence
  • Pourquoi il est important de la mesurer correctement
  • Erreurs fréquentes à éviter dans l’examen de vos données de latence
  • L’importance des commentaires instantanés
  • Pourquoi des données non échantillonnées sont nécessaires

Qu’est-ce que la latence ?

Dictionary.com (lien externe à ibm.com) définit la latence comme « la période de retard pendant laquelle un composant d’un système matériel attend qu’une action soit exécutée par un autre composant ». En termes plus simples, il s’agit du délai entre l’appel d’une fonction et son exécution réelle. La latence est inhérente à tous les systèmes ; même si nous disposions d’un système parfait, ce qui n’existe pas, il y aurait une latence correspondant au temps nécessaire aux électrons de l’ordinateur pour faire passer les transistors de l’état actif à l’état inactif ou vice versa.

La latence dans les petites opérations n’est pas énorme, mais lorsque vous gérez des millions d’opérations, il y a des millions de latences qui s’accumulent rapidement. La latence n’est pas définie par les unités de travail et le temps, mais plutôt par son comportement. Les outils de surveillance signalent le temps nécessaire entre le début et la fin d’une fonction.

La latence peut avoir un impact majeur sur votre entreprise. Par exemple (lien externe à ibm.com) : « En termes de vitesse mobile, chaque seconde compte : pour chaque seconde supplémentaire nécessaire au chargement d’une page mobile, les conversions peuvent diminuer de 20 %. »

Erreurs fréquentes à éviter dans l’examen de vos données de latence

La latence ne suit presque jamais une distribution gaussienne ou poissonienne normale. Même si votre latence suit l’une de ces distributions, en raison de la façon dont nous observons la latence, elle rend les moyennes, les médianes et même les écarts-types inutiles. Si, par exemple, vous mesurez le chargement des pages, 99,9999999999 % de ces charges peuvent être en deçà de votre médiane. C’est en partie la raison pour laquelle l’échantillonnage aléatoire de la latence génère des données inexactes, mais nous en reparlerons plus tard.

À ce stade, vous vous demandez probablement si nous n’utilisons aucun écart-type, comment pouvons-nous décrire les latences de manière significative ? La réponse est que nous devons examiner les percentiles et les maximums. La plupart des gens se disent, je vais donc observer la mesure P95 pour comprendre la tendance générale. Le problème avec cette méthode est que P95 va masquer tous les mauvais éléments. Comme l’explique Gil Tene, directeur technique d’Azul Systems : « C’est un système marketing qui est trompeur. »

Prenons par exemple ce graphique :

Lorsque vous voyez ce graphique, vous pouvez clairement voir pourquoi sa médiane et sa moyenne n’ont pas de signification réelle : elles ne montrent pas la zone problématique. Lorsque vous voyez le 95e centile monter vers la gauche, vous pensez que vous êtes au cœur du problème. Bien sûr, ce n’est pas vrai. Lorsque vous recherchez pourquoi votre programme a eu un accroc, vous ne parvenez pas à identifier les 5 % qui posent problème. Pour obtenir ce type de pic, il faut que les 5 % de données les plus performantes soient nettement pires.

Regardez maintenant le même graphique qui montre également le 99,99e centile :

Cette ligne rouge correspond au 95e centile, tandis que la ligne verte correspond au 99,99e centile. Comme vous pouvez le voir clairement, le 95e fournir ne montre que 2 problèmes sur 22 et voilà pourquoi vous devez examiner l’ensemble de vos données.

Beaucoup pensent que les 5 derniers % de données n’ont pas tant d’importance. Bien sûr, il peut s’agir du redémarrage d’une machine virtuelle (VM), d’un accroc dans votre système ou autre, mais en l’ignorant, vous dites que cela n’arrive jamais alors qu’il peut s’agir de l’un des éléments les plus importants à cibler.

Gil Tene aime affirmer « L’indicateur numéro un dont vous ne devriez jamais vous débarrasser est la valeur maximale. Il ne s’agit pas de bruit, c’est le signal. Le reste, c’est du bruit. » Bien que le maximum soit en effet un excellent choix dans un système à grande échelle, il n’est souvent pas pratique de se limiter au cas maximal. Aucun système n’est parfait et des accrocs se produisent. Dans un système pratique à grande échelle, poursuivre exclusivement le cas maximum est souvent un bon moyen d’épuiser les développeurs.

Le 99,99e centile vous permet de voir ce qui se passe pour la grande majorité de vos clients, et les pics d’activité que vous voyez sont de véritables problèmes, tandis que les pics d’activité de votre maximum peuvent n’être qu’un hiérarchisation de votre système. Lorsque vos équipes DevOps concentrent leurs efforts sur ces petits obstacles, le coût est important, car elles ne peuvent pas se consacrer à des problèmes plus importants.

Il est important de noter que si votre 99,99e centile et votre maximum sont très proches l’un de l’autre, et qu’ils connaissent tous deux un pic, c’est un signal formidable : c’est un problème sur lequel votre équipe doit travailler. Ainsi, M. Gil a raison sur le fait que le maximum est un signal important, mais il a tort de dire que le reste de vos données n’est que du bruit. Comme vous pouvez le voir sur ce graphique, notre 99,99e centile et le maximum calculés dans notre exemple précédent correspondent exactement. C’est un signal fort qui dénote un véritable bogue et pas un simple accroc :

Percentiles moyens : comment le pré-calcul vous entraîne à mal mesurer la latence

Un piège encore pire que le simple fait de regarder le 95e percentile est de ne pas reconnaître que leurs percentiles sont une moyenne. Le calcul du nombre de percentiles est statistiquement absurde ; il élimine toute signification significative de ce que vous voyez. Nous avons déjà montré que les moyennes ne sont pas bonnes en termes de latence et, si vous examinez les percentiles moyens, vous êtes simplement de retour au zéro. De nombreux logiciels font la moyenne de vos percentiles. Prenons par exemple ce graphique Grafana :

Que vous l’ayez déjà réalisé ou non, tous les percentiles de ce graphique sont des moyennes. C’est indiqué directement dans le grand livre de l’axe des x. Presque tous les services de surveillance font la moyenne de vos percentiles. C’est une réalité liée au pré-calcul. Lorsque votre service de surveillance recueille vos données, il calcule le centile des données pour cette minute.

Ensuite, quand vous regardez votre 95e percentile, il vous montre une moyenne de tous vos percentiles. Ce raccourci est censé être « pour votre bien », pour rendre votre service plus rapide, mais il consiste en réalité à retirer tout sens statistique à vos données.

Pourquoi vous devez disposer de données non échantillonnées pour mesurer correctement la latence

Que vous le sachiez ou non, les outils de surveillance participant à l’échantillonnage des données produisent des données moyennes. Presque tous les outils de surveillance échantillonnent leurs données. Prenons par exemple Datadog qui subit une perte de données importante. Si vous envoyez 3 millions de points en une minute, il ne les acceptera pas tous. Au lieu de cela, il échantillonnera les points de manière aléatoire puis les regroupera à un niveau de 1 point par minute.

Vous devez avoir des données non échantillonnées pour comprendre votre temps de latence. Il est évident qu’avec des données échantillonnées, vous ne pouvez pas accéder à la distribution complète. Votre maximum n’en est pas vraiment un, et votre centile global n’est pas une représentation précise de ce qui se passe.

Utiliser le logiciel IBM Instana pour mesurer efficacement la latence

Lorsque vous échantillonnez des données, vous en omettez un certain nombre. Supposons, par exemple, que vous ayez 10 000 opérations à effectuer en une minute, et envoyiez 2 points de données chacun à votre système de surveillance. Supposons qu’il y ait un bogue dans votre système et que l’un de ces points de données affiche ce bogue pour 10 000 opérations. Votre système de surveillance n’a qu’une chance sur 20 000 de choisir ce bogue comme point de données qu’il vous indique comme étant le maximum.

Si vous effectuez des analyses suffisamment longtemps, le point de données finira par apparaître, mais il ressemblera alors à un cas marginal sporadique, même s’il se produit chez l’un de vos clients toutes les minutes. Lorsque vous n’échantillonnez pas les données et que vous avez l’un de ces pics, ils apparaîtront clairement dans votre 99,99e centile, et votre maximum se révélera à proximité, ce qui indique qu’il y a un bogue dans votre programme. Cependant, lorsque vous échantillonnez vos données, elles seront moins fréquentes, ce qui signifie que vous ne les verrez pas comme un bogue, mais plutôt comme un accroc. Votre équipe d’ingénierie ne parviendra pas à se rendre compte de l’importance de ce résultat.

Ne laissez pas votre outil de surveillance vous faire croire que vous savez ce qui se passe avec votre latence. Une des fonctionnalités principales du logiciel IBM Instana est sa capacité à mesurer efficacement la latence. Le logiciel IBM Instana utilise des analyses avancées et le machine learning (ML) pour détecter automatiquement les problèmes de latence en temps réel, permettant aux développeurs et aux équipes informatiques d’identifier rapidement la cause racine de tous les problèmes de performance et de prendre des mesures correctives avant qu’ils n’affectent les utilisateurs.

Choisissez un outil qui ne fournit pas de données échantillonnées. Choisissez un outil qui ne fait pas la moyenne de vos percentiles globaux.

Solutions connexes
IBM Cloud Pak for Network Automation 

IBM Cloud Pak for Network Automation est un Cloud Pak qui automatise et orchestre les opérations d’infrastructure réseau.

Découvrir l’automatisation Cloud Pak
Solutions de mise en réseau

Les solutions de mise en réseau cloud d’IBM assurent une connectivité haute performance pour alimenter vos applications et vos activités.

Découvrir les solutions de mise en réseau cloud
Services de support réseau

Consolidez le support du centre de données avec IBM Technology Lifecycle Services pour la mise en réseau cloud et plus encore.

Services de mise en réseau cloud
Passez à l’étape suivante

Renforcez votre entreprise grâce à des solutions de pointe en matière de gestion DNS et de mise en réseau cloud. Améliorez la fiabilité de vos applications et optimisez les performances de votre réseau grâce aux services de pointe d’IBM.

Découvrir les solutions de mise en réseau cloud Découvrir les services DNS gérés