SRE : Analyse de performance. Méthode de configuration utilisant un serveur web simple en Go

L'analyse de performance et l'optimisation sont des outils puissants pour vérifier la conformité des performances pour les clients.

L'analyse de performance peut être utilisée pour identifier les goulets d'étranglement dans le programme, en appliquant une approche scientifique lors de l'évaluation des expériences d'optimisation. Cet article définit une approche générale pour l'analyse de performance et l'optimisation, en utilisant un serveur web en Go comme exemple.

Go convient particulièrement bien à cette fonction, car il dispose d'outils de profilage. pprof dans la bibliothèque standard.

Stratégie

Créons une liste récapitulative pour notre analyse structurelle. Nous essaierons d'utiliser des données pour prendre des décisions plutôt que d'apporter des modifications basées sur l'intuition ou des suppositions. Pour ce faire, procédons comme suit :

• Définissons les limites de l'optimisation (exigences) ;
• Calculons la charge transactionnelle du système ;
• Effectuons un test (créons des données) ;
• Observons ;
• Analysons — toutes les exigences sont-elles respectées ?
• Optimisons de manière scientifique, formulons une hypothèse ;
• Réaliser une expérience pour vérifier cette hypothèse.

Architecture d'un simple serveur HTTP

Pour cet article, nous allons utiliser un petit serveur HTTP en Golang. Tout le code de cet article est disponible. ici.

L'application analysée est un serveur HTTP qui interroge PostgreSQL pour chaque requête. En complément, nous avons Prometheus, node_exporter et Grafana pour collecter et afficher les métriques de l'application et du système.

Pour simplifier, considérons que pour le scaling horizontal (et pour simplifier les calculs), chaque service et base de données est déployé ensemble :

Définissons les objectifs

À cette étape, nous clarifions notre objectif. Que cherchons-nous à analyser ? Comment saurons-nous qu'il est temps de conclure ? Dans cet article, nous supposerons que nous avons des clients et que notre service traitera 10 000 requêtes par seconde.

Dans Google SRE Book Nous examinerons en détail les méthodes de sélection et de modélisation. Procédons de même, en construisant des modèles :

• Latence : 99 % des requêtes doivent être exécutées en moins de 60 ms ;
• Coût : le service doit consommer le montant le plus faible, que nous jugeons raisonnablement possible. Pour cela, nous maximisons le débit ;
• Planification des capacités : il est nécessaire de comprendre et de documenter combien d'instances d'application doivent être lancées, y compris la fonction globale de mise à l'échelle, ainsi que combien d'instances sont nécessaires pour répondre aux exigences initiales de charge et garantir la redondance n+1.

La latence peut nécessiter des optimisations en plus de l'analyse, mais la bande passante doit clairement être analysée. Dans le cadre du processus SRE, l'exigence en matière de latence provient du client et/ou de l'entreprise, représentée par le propriétaire du produit. Et notre service répondra à cet engagement dès le départ, sans aucune configuration !

Configuration d'un environnement de test

Grâce à l'environnement de test, nous pourrons imposer une charge mesurée à notre système. Des données sur les performances du service web seront créées pour l'analyse.

Charge transactionnelle

Cet environnement utilise Vegeta pour créer une fréquence de requêtes HTTP personnalisée jusqu'à ce qu'il soit arrêté :

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

Surveillance

Pendant l'exécution, une charge transactionnelle sera appliquée. En plus des métriques de l'application (nombre de requêtes, latences de réponse) et du système d'exploitation (mémoire, CPU, IOPS), un profilage de l'application sera lancé pour comprendre où se trouvent les problèmes et comment le temps processeur est consommé.

Profilage

Le profilage est un type de mesure permettant de voir où va le temps processeur lors de l'exécution de l'application. Il permet de déterminer où et combien le temps processeur est dépensé :

Ces données peuvent être utilisées lors de l'analyse pour obtenir un aperçu du temps processeur dépensé inutilement et des tâches exécutées sans nécessité. Go (pprof) peut générer des profils et les visualiser sous forme de flame graph, en utilisant un ensemble d'outils standard. Je parlerai de leur utilisation et de la configuration dans un moment dans l'article.

Exécution, surveillance, analyse.

Nous allons mener une expérience. Nous exécuterons, observerons et analyserons jusqu'à ce que la performance nous satisfasse. Nous choisirons une faible charge de manière aléatoire pour l'utiliser afin d'obtenir les résultats des premières observations. À chaque étape suivante, nous augmenterons la charge avec un certain facteur d'échelle, choisi avec une certaine dispersion. Chaque exécution de test de charge se fait avec un ajustement du nombre de requêtes : make load-test LOAD_TEST_RATE=X.

50 requêtes par seconde

Notez les deux graphiques en haut. Le supérieur gauche montre que notre application traite 50 requêtes par seconde (à son avis), tandis que le supérieur droit indique la durée de chaque requête. Ces deux paramètres nous aident à observer et à analyser : sommes-nous dans nos limites de performance ou non. La ligne rouge sur le graphique Latence des requêtes HTTP indique un SLO de 60 ms. On voit sur la ligne que nous sommes bien en dessous de notre temps de réponse maximal.

Voyons du côté des coûts :

10000 requêtes par seconde / 50 requêtes par serveur = 200 serveurs + 1

Nous pouvons encore améliorer ce chiffre.

500 requêtes par seconde

Des choses plus intéressantes commencent à se produire lorsque la charge atteint 500 requêtes par seconde :

Encore une fois, sur le graphique supérieur gauche, on voit que l'application enregistre une charge normale. Si ce n'est pas le cas, il y a un problème avec le serveur sur lequel l'application est exécutée. Le graphique de latence de réponse en haut à droite montre que 500 requêtes par seconde ont conduit à une latence de réponse de 25-40 ms. Le 99ème percentile reste largement dans le SLO de 60 ms choisi précédemment.

Du point de vue des coûts :

10000 requêtes par seconde / 500 requêtes par serveur = 20 serveurs + 1

Il est encore possible d'améliorer.

1000 requêtes par seconde

Excellente exécution ! L'application montre qu'elle a traité 1000 requêtes par seconde, cependant la limite de latence a été dépassée du côté du SLO. Cela se voit sur la ligne p99 du graphique supérieur droit. Bien que la ligne p100 soit bien plus haute, les latences réelles dépassent le maximum de 60 ms. Plongeons dans le profilage pour voir ce que fait réellement l'application.

Profilage

Pour le profilage, nous plaçons la charge à 1000 requêtes par seconde, puis utilisons pprof pour collecter des données afin de déterminer où l'application consomme du temps processeur. Cela peut être fait en activant le point de terminaison HTTP. pprof, puis en chargeant les résultats avec curl :

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

Les résultats peuvent être affichés comme suit :

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

Le graphique montre où et combien l'application dépense de temps CPU. D'après la description de Brendan Gregg:

L'axe X représente le remplissage du profil de la pile, trié par ordre alphabétique (ce n'est pas le temps), l'axe Y montre la profondeur de la pile, commençant à zéro dans [top]. Chaque rectangle représente un cadre de la pile. Plus le cadre est large, plus il apparaît souvent dans les piles. Ce qui est en haut fonctionne sur le CPU, et en bas se trouvent les éléments enfants. Les couleurs, en général, ne signifient rien, elles sont simplement choisies au hasard pour distinguer les cadres.

Analyse — hypothèse

Pour la configuration, nous nous concentrerons sur la recherche des gaspillages inutiles de temps CPU. Nous allons chercher les plus grandes sources de dépenses inutiles et les supprimer. Et étant donné que le profilage révèle très précisément où l'application dépense son temps CPU, il faudra peut-être le faire plusieurs fois, et il sera également nécessaire de modifier le code source de l'application, de redémarrer les tests et d'observer que les performances se rapprochent de ce qui est prévu.

En suivant les recommandations de Brendan Gregg, nous allons lire le graphique de haut en bas. Chaque ligne représente un cadre de la pile (appel de fonction). La première ligne est le point d'entrée de la programme, parent de tous les autres appels (en d'autres termes, tous les autres appels auront cette ligne dans leur pile). La ligne suivante est déjà différente :

Si l'on survole le nom de la fonction sur le graphique, le temps total qu'elle a passé dans la pile pendant le débogage s'affiche. La fonction HTTPServe y était présente 65 % du temps, d'autres fonctions runtime, runtime.mcall, mstart et gc, ont pris le reste du temps. Fait intéressant : 5 % du temps total a été consacré aux requêtes DNS :

Les adresses que le programme recherche appartiennent à Postgresql. Cliquez sur FindByAge:

Il est intéressant de noter que le programme montre qu'il y a essentiellement trois sources principales qui ajoutent des délais : l'ouverture et la fermeture des connexions, la requête de données et la connexion à la base. Sur le graphique, on voit que les requêtes DNS, l'ouverture et la fermeture des connexions représentent environ 13 % du temps d'exécution total.

Hypothèse : La réutilisation des connexions via un pool devrait réduire le temps d'une requête HTTP, permettant une plus grande bande passante et des délais plus courts..

Configuration de l'application — expérience.

Nous mettons à jour le code source, essayons de supprimer la connexion à Postgresql pour chaque requête. Première option — utilisation. du pool de connexions. au niveau de l'application. Dans cette expérience, nous allons configurer un pool de connexions à l'aide du pilote SQL pour Go :

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

Exécution, observation, analyse.

Après le redémarrage du test avec 1000 requêtes par seconde, il est clair que le p99 des délais est revenu à la normale avec un SLO de 60 ms !

Qu'en est-il du coût ?

10000 requêtes par seconde / à 1000 requêtes par serveur = 10 serveurs + 1.

Faisons encore mieux !

2000 requêtes par seconde.

Le doublement de la charge montre la même chose, le graphique en haut à gauche montre que l'application parvient à traiter 2000 requêtes par seconde, p100 inférieur à 60 ms, p99 respecte le SLO.

Du point de vue des coûts :

10000 requêtes par seconde / à 2000 requêtes par serveur = 5 serveurs + 1.

3000 requêtes par seconde.

Ici, l'application peut traiter 3000 requêtes avec un retard p99 inférieur à 60 ms. Le SLO n'est pas enfreint, et le coût est pris comme suit :

10000 requêtes par seconde / à 3000 requêtes par serveur = 4 serveurs + 1. (l'auteur a arrondi au supérieur, note du traducteur)

Essayons un autre round d'analyse.

Analyse — hypothèse

Nous collectons et affichons les résultats du débogage de l'application à 3000 requêtes par seconde :

6 % du temps est encore consacré à l'établissement des connexions. La configuration du pool a amélioré la performance, mais il est clair que l'application continue de créer de nouvelles connexions avec la base.

Hypothèse : Les connexions, malgré la présence du pool, sont toujours rejetées et nettoyées, donc l'application doit les rétablir. Fixer le nombre de connexions en attente à la taille du pool devrait aider avec le délai en minimisant le temps que l'application consacre à la création de connexions..

Configuration de l'application — expérience.

Essayons de fixer MaxIdleConns à la taille du pool (décrit également ici):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

Exécution, observation, analyse.

3000 requêtes par seconde.

p99 inférieur à 60 ms avec un p100 nettement inférieur !

La vérification du flame graph montre que l'établissement de la connexion n'est plus perceptible ! Vérifions en détail. pg(*conn).query — nous ne remarquons également pas d'établissement de connexion ici.

Conclusion

L'analyse de la performance est essentielle pour comprendre si les attentes des clients et les exigences non fonctionnelles sont satisfaites. L'analyse par la mise en correspondance des observations avec les attentes des clients peut aider à déterminer ce qui est acceptable et ce qui ne l'est pas. Go fournit des outils efficaces, intégrés dans la bibliothèque standard, qui rendent l'analyse simple et accessible.

Source : habr.com