Partager via

Optimisation des performances d’une application distribuée

  • Article

Dans cette série, nous allons parcourir plusieurs scénarios d’applications cloud, qui montrent comment une équipe de développement a utilisé des tests de charge et des métriques pour diagnostiquer les problèmes de performances. Ces articles sont basés sur des tests de charge réels que nous avons effectués lors du développement d’exemples d’applications. Le code pour chaque scénario est disponible sur GitHub.

Scénarios :

Qu’est-ce que les performances ?

Les performances sont fréquemment mesurées en termes de débit, de temps de réponse et de disponibilité. Les objectifs de performances doivent être basés sur des opérations métier. Les tâches orientées client peuvent avoir des exigences plus strictes que des tâches opérationnelles, comme la génération de rapports.

Définissez un objectif de niveau de service (SLO, Service Level Objective) qui définit les cibles de performances pour chaque charge de travail. Vous atteignez généralement cet objectif en décomposant une cible de performances en un ensemble d’indicateurs de performance clés (KPI), comme par exemple :

  • Latence ou temps de réponse de demandes spécifiques
  • Nombre de demandes exécutées par seconde
  • Débit avec lequel le système génère des exceptions.

Les cibles de performances doivent inclure explicitement une charge cible. De même, tous les utilisateurs ne reçoivent pas exactement le même niveau de performances, même s’ils accèdent au système simultanément et y effectuent le même travail. Ainsi, un SLO doit être exprimé en termes de centiles.

Un exemple de SLO peut être : « Les demandes client ont une réponse dans un délai de 500 ms au 90ème centile, à des charges allant jusqu’à 25 000 demandes par seconde. »

Difficultés liées à l’optimisation des performances d’un système distribué

Il peut être particulièrement difficile de diagnostiquer les problèmes de performances dans une application distribuée. Voici quelques-unes des difficultés :

  • Une même transaction ou opération métier implique généralement plusieurs composants du système. Il peut être difficile d’obtenir une vue globale de bout en bout d’une même opération.

  • La consommation des ressources est distribuée entre plusieurs nœuds. Pour obtenir une vue cohérente, vous devez agréger les journaux et les métriques à un même emplacement.

  • Le cloud offre une mise à l’échelle élastique. La mise à l’échelle automatique est une technique importante pour la gestion des pics de charge, mais elle peut également masquer des problèmes sous-jacents. En outre, il peut être difficile de savoir quels composants doivent être mis à l’échelle et à quel moment.

  • Souvent, les charges de travail ne se mettent pas à l’échelle entre les cœurs ou les threads. Il est important de comprendre les exigences de vos charges de travail et d’étudier des tailles mieux optimisées. Certaines tailles offrent des cœurs limités et un hyperthreading désactivé pour améliorer les charges de travail orientées cœur unique et par cœur sous licence.

  • Les défaillances en cascade peuvent entraîner des défaillances en amont du problème racine. Par conséquent, le premier signal du problème peut apparaître dans un composant autre que celui de la cause racine.

Bonnes pratiques générales

L’optimisation des performances est à la fois un art et une science, mais elle peut être rendue plus proche de la science si vous adoptez une approche systématique. Voici quelques bonnes pratiques :

  • Activez la télémétrie pour collecter des métriques. Instrumentez votre code. Suivez les bonnes pratiques pour la supervision. Utilisez un suivi corrélé pour pouvoir observer toutes les étapes d’une transaction.

  • Supervisez les 90/95/99èmes centiles, et pas seulement la moyenne. La moyenne peut masquer les valeurs hors norme. Le taux d’échantillonnage pour les métriques est également important. Si le taux d’échantillonnage est trop faible, il peut masquer des pics ou des valeurs hors norme qui peuvent indiquer des problèmes.

  • Attaquez un seul goulot d’étranglement à la fois. Formez une hypothèse et testez-la en changeant une seule variable à la fois. La suppression d’un goulet d’étranglement dévoile souvent un autre goulot d’étranglement en amont ou en aval.

  • Les erreurs et les nouvelles tentatives peuvent avoir un impact important sur les performances. Si vous constatez que les services back-end limitent votre système, effectuez un scale-out ou essayez d’optimiser l’utilisation (par exemple, en paramétrant les requêtes de base de données).

  • Recherchez les anti -modèles de performances courants.

  • Recherchez les possibilités de parallélisation. Les files d’attente de messages et les bases de données sont deux sources courantes de goulots d’étranglement. Dans les deux cas, le partitionnement peut vous aider. Pour plus d’informations, consultez Partitionnement horizontal, vertical et fonctionnel des données. Recherchez les partitions très sollicitées, qui peuvent indiquer des charges d’écriture ou de lecture déséquilibrées.

Étapes suivantes

Lire les scénarios d’optimisation des performances