Comment savoir que l’API ralentit ?

Une solution statistique pour savoir s’il est temps de refactoriser votre code

Le ralentissement de l’API a un impact important sur l’expérience utilisateur ou même sur la perte de confiance, nous voulons donc toujours connaître la latence le plus tôt possible.

Par conséquent, il est courant d’intégrer des tests de performance et des repères de mesure dans les tests d’automatisation.

Mais la notion de lenteur est très difficile à évaluer.

• Est-ce arrivé par accident? Ou est-ce un statut permanent ?
• Est-ce dû à l’environnement expérimental ? Ou est-ce un effet secondaire du code ?
• Est-ce le résultat de fonctionnalités accrues ? Ou est-ce un défaut ?

Il est difficile d’avoir une réponse claire à ces questions.

En supposant que nous ayons un moyen de détecter « lent », nous enverrons une alarme ou un rapport. Mais s’il ne s’agit que d’une « coïncidence » ou d’une fausse alerte causée par des environnements expérimentaux, les gens finiront par essayer d’ignorer ces signaux.

De plus, il faut s’attendre à ce que les API ralentissent à mesure que des fonctionnalités sont ajoutées. Lorsque nous avons plus de paramètres, plus de logique métier, et plus if-elseil n’est pas étonnant que le temps de réponse ralentisse.

De plus, si nous utilisons un seuil pour éviter le problème ci-dessus, lorsque nous reconnaissons vraiment le ralentissement de l’API, nous ne saurons pas quelle est la cause première du ralentissement.

Tous ces facteurs rendent la tâche de détection des ralentissements de l’API extrêmement difficile.

Pour résoudre les problèmes mentionnés, résumons les exigences.

1. être en mesure de savoir précisément quand le problème survient
2. pour pouvoir autoriser les valeurs aberrantes accidentelles
3. pouvoir éviter le phénomène normal de montée lente
4. pouvoir émettre des alarmes

Examinons d’abord un schéma.

• L’axe horizontal indique chaque test, qui peut être considéré comme une version temporelle ou de version, ou même s’il est intégré au pipeline CI/CD, c’est-à-dire chaque validation.
• L’axe vertical représente la latence des tests cibles.
• La ligne rouge est le personnage principal de cet article, Régression linéaire.

D’après le diagramme, nous pouvons savoir avant un certain temps, essentiellement la latence augmente lentement, mais après un certain temps, toute la latence augmente rapidement. Et ce moment est le problème que nous voulons connaître.

Peut-être me direz-vous qu’il est facile de le savoir à l’œil nu en regardant les chiffres à chaque fois ? Après tout, c’est assez intuitif.

La clé est l’échelle de la latence. Si la moyenne des points de données du groupe ci-dessous est de 0,1 seconde et que le groupe derrière est de 0,2 seconde, vous sentirez-vous toujours très intuitif ?

Par conséquent, nous avons besoin d’une norme respectueuse du cerveau, c’est-à-dire la régression linéaire.

Grâce à la régression linéaire, nous pouvons savoir que la tendance générale de l’ensemble de données est à la hausse. Cependant, cela ne suffit pas, car le simple fait de savoir que la tendance est à la hausse ne signifie pas que nous pouvons juger si elle est normale ou anormale.

Le groupe de points de données denses du front est également en hausse, alors comment pouvons-nous déterminer que la tendance est anormale et que le front est normal ?

Regardons un autre schéma.

Question : La latence de ce diagramme est-elle normale ou anormale ?

Cela ressemble beaucoup au diagramme précédent, il y a une nette tendance à la hausse, donc ça devrait être anormal, non ? Ah bon?

Ajoutons quelques points de référence et dézoomons un peu.

As-tu trouvé? Le diagramme ci-dessus est en fait une partie normale du diagramme d’origine, juste une montée lente.

En effectuant simplement une analyse de régression linéaire sur un seul ensemble de données, nous pouvons obtenir des conclusions erronées car nous n’avons pas de référence de comparaison et ne pouvons pas dire s’il s’agit d’un phénomène naturel causé par des fonctionnalités accrues ou d’un problème causé par des défauts.

Revenons à notre question, comment pouvons-nous détecter le problème le plus tôt possible sans faux positifs ?

Tout d’abord, nous devons choisir un point de référence, par exemple, il y a un jour. Ensuite, nous effectuons une régression linéaire sur l’ensemble des données pour obtenir une ligne rouge. Bien sûr, nous devons également effectuer une régression linéaire sur les données avant le point de référence, ce qui conduira à la ligne verte.

La pente de la ligne rouge et de la ligne verte est utilisée pour calculer l’angle comme base de jugement. En d’autres termes, lorsque l’angle entre la ligne rouge et la ligne verte est plus grand, il est plus probable qu’il soit anormal.

Par conséquent, le seuil de déclenchement d’une alarme n’est ni la latence elle-même ni la pente, mais l’angle des deux lignes.

Étant donné que les pentes des deux lignes sont k1 et k2, la formule de l’angle θ est la suivante.

En Python, ce serait :

import math
thera = math.degrees(math.atan2(abs(k2 - k1), abs(1 + k1 * k2)))
# atan2 does not need to handle denominator zero error cases
# If we use atan
# we need to solve the case where k1 * k2 is equal to -1 first

Nous pouvons faire plusieurs expériences avec des valeurs simulées pour obtenir notre seuil d’alarme idéal.

Enfin, en plus du seuil d’angle, nous avons également besoin d’un autre indicateur d’alarme, qui est la limite supérieure de la latence autorisée.

Pourquoi faut-il fixer une borne supérieure ?

Parce que si notre latence continue d’augmenter dans une tendance de ligne verte, elle atteindra un jour une valeur inacceptable, mais si nous fixons simplement le seuil d’angle, nous ne saurons jamais à quel point la situation est grave jusqu’à ce que nous ayons un désastre sur la production.

Enfin, voici un exemple de calcul de régression linéaire en Python.

import numpy as np
from sklearn.linear_model import LinearRegression
# raw_x and raw_y are the results of each test
# raw_x can be a time, version or commit normalization
# raw_y are latencies
x = np.array(raw_x)[:, np.newaxis]
y = np.array(raw_y)[:, np.newaxis]
bfl = LinearRegression()
bfl.fit(x,y)
y_pred = bfl.predict(x)
slope = bfl.coef_[0, 0]

Alors, comment savoir si l’API ralentit ? Nous avons besoin de deux alertes.

1. l’angle entre la ligne de données actuelle et la ligne de données du point de référence après régression linéaire.
2. la borne supérieure maximale de la latence.

Lorsque nous avons ces deux alarmes, nous pouvons savoir exactement quand le code pose problème et s’il est temps de refactoriser le système.

En fait, il s’agit d’une approche statistique pour atteindre l’objectif, mais il y a encore quelques inconvénients à cela. Par exemple, comment définir la valeur seuil de l’angle de pente ? Comment choisir le point de référence ? Quelle est la fourchette statistique à choisir ? Toutes ces questions nécessitent des expériences pour trouver les réponses.

Par conséquent, le moyen le plus efficace consiste à introduire l’apprentissage automatique dans le système d’analyse de latence et à juger si le résultat actuel est normal ou anormal via le modèle de prédiction, plutôt que via des paramètres humains. Il est plus difficile pour les humains de porter des jugements que pour les machines.

Cependant, la construction d’un modèle d’apprentissage automatique nécessite des connaissances et des compétences dans le domaine correspondant, qui peuvent ne pas convenir aux petites organisations. La régression linéaire est donc une solution fiable et peu coûteuse.