Tests et antimodèles de performance pour les applications cloud
Les antimodèles de performance, tout comme les modèles de conception, sont des processus et des implémentations défectueux courants au sein des organisations. Voici des pratiques courantes susceptibles de causer des problèmes de scalabilité lorsqu’une application est sous pression. La connaissance de ces pratiques peut aider à simplifier la communication de concepts de haut niveau entre les utilisateurs du logiciel. De plus, la connaissance des anti-modèles peut être utile lors de l’examen du code ou lors du diagnostic des problèmes de performances.
Voici un scénario courant : une application se comporte correctement lors du test de performance. Elle est mise en production et commence à gérer des charges de travail réelles. À ce stade, elle commence à fonctionner médiocrement, rejetant des demandes utilisateur, se bloquant ou levant des exceptions. L’équipe de développement est alors confrontée à deux questions :
- Pourquoi ce comportement n’est-il pas apparu pendant les tests ?
- Comment le corriger ?
La réponse à la première question est simple. Il est difficile de simuler de vrais utilisateurs dans un environnement de test, de même que leurs modèles de comportement et leurs volumes de travail possibles. La seule façon permettant de comprendre avec certitude comment un système se comporte sous charge consiste à l’observer en production. Pour être clair, nous ne vous suggérons pas d’ignorer les tests de performances. Les tests de performances sont essentiels pour obtenir des métriques de performances de référence. Mais vous devez être prêt à observer et corriger des problèmes de performances lorsqu’ils se produisent dans le système réel.
La réponse à la deuxième question (comment résoudre le problème) est moins simple. Un grand nombre de facteurs peuvent y contribuer, et il arrive que le problème ne se manifeste que dans certaines circonstances. L’instrumentation et la journalisation sont essentielles pour rechercher la cause racine, mais vous devez également savoir quoi rechercher.
À partir de nos engagements avec les clients de Microsoft Azure, nous avons identifié certains des problèmes de performances les plus courants auxquels ils sont confrontés en production. Pour chaque anti-modèle, nous décrivons pourquoi il se produit généralement, ses symptômes et les techniques pour résoudre le problème. Nous fournissons également des exemples de code illustrant l’antimodèle et une suggestion de solution de scalabilité.
Certains de ces anti-modèles peuvent sembler évidents lorsque vous lisez les descriptions, mais ils se produisent plus souvent que vous ne le pensez. Parfois, une application hérite d’une conception qui a fonctionné localement, mais qui ne s’étend pas dans le cloud. Ou alors une application peut démarrer avec une conception très claire mais l’ajout de nouvelles fonctionnalités peut faire apparaître un ou plusieurs de ces anti-modèles. Dans tous les cas, ce guide vous aidera à identifier et résoudre ces anti-modèles.
Catalogue des anti-modèles
Voici la liste des anti-modèles que nous avons identifiés :
| Anti-modèle | Description |
|---|---|
| Base de données occupée | Déchargement d’un traitement excessif dans un magasin de données. |
| Front-end occupé | Déplacement de tâches gourmandes en ressources vers des threads d’arrière-plan. |
| E/S bavarde | Envoi continu de nombreuses petites requêtes réseau. |
| Récupération superflue | Récupération de données plus que nécessaire, entraînant des E/S inutiles. |
| Instanciation incorrecte | Création et destruction répétées d’objets conçus pour être partagés et réutilisés. |
| Persistance monolithique | Utilisation d’un même magasin de données pour des données ayant des modèles d’utilisation très différents. |
| Aucune mise en cache | Échec de la mise en cache des données. |
| Voisin bruyant | Un locataire unique utilise une quantité disproportionnée des ressources. |
| Tempête de nouvelles tentatives | Demandes de connexion à un serveur retentées trop souvent. |
| E/S synchrone | Blocage du thread appelant lorsque l’E/S se termine. |
Étapes suivantes
Pour plus d’informations sur le réglage des performances, consultez Réglage des performances d’une application distribuée.