Cet article ne traite pas des types de problèmes de performances rencontrés par un système de stockage de fichiers en cluster; au contraire, il approfondira le processus de recherche rapide de ces problèmes et de leur suppression.
Cela étant dit, de nombreuses anecdotes et procédures sont basées sur le domaine des systèmes distribués. L'application de cette idéologie à des systèmes intégrés ou à d'autres domaines radicalement différents peut ne pas s'avérer significative.
Maintenir la performance
L'écriture de code performant devrait toujours être un objectif du logiciel, mais ce n'est souvent pas la première priorité. Pour de nombreux développeurs, le code est correct tant qu'il passe tous les tests et c'est tout. En raison de ce comportement, l'une des premières et des plus critiques étapes pour obtenir de bonnes performances consiste à intégrer des critères de performances dans des tests de «correction». Cela permet d'éviter les régressions de performances et, si elles sont combinées avec un profilage détaillé, ces tests peuvent fournir les données nécessaires à l'analyse des performances. Bien que le maintien des performances implique le fait que les performances sont déjà élevées, cela devrait être la première priorité des performances. Sans cela, les changements qui régressent les performances sont beaucoup plus difficiles à diagnostiquer et à prévenir.
Obtenir des performances
La première étape pour améliorer les performances consiste à choisir un type ou un scénario qui devrait être amélioré. Cela implique d'écrire un test de performance qui catégorise ce scénario, s'il n'existe pas déjà, et d'obtenir une référence. Afin de collecter des données utiles et concrètes, de nouveaux systèmes devront peut-être être créés ou utilisés. Des outils comme compteurs de performance et traçage du système sont d'excellents points de départ et les idées qui les sous-tendent peuvent être facilement étendues pour mesurer l'utilisation dans le code à améliorer.
Maintenant que tous les prérequis sont couverts, nous pouvons commencer à itérer. Avec des systèmes en place pour mesurer à la fois les performances globales et fines, le meilleur endroit pour commencer est souvent n'importe quel système utilisant une grande quantité d'une ou de plusieurs ressources système. Selon le produit, le goulot d'étranglement peut se trouver dans de nombreux systèmes différents. L'effet secondaire majeur d'un goulot d'étranglement est que le travail est bloqué dans une file d'attente quelque part dans le système. Cela peut se manifester par un système fonctionnant à sa capacité maximale ou presque ou par autant de tâches inactives au même point. Une fois que nous savons quel système est surutilisé, il est temps de faire une hypothèse sur la raison pour laquelle ce système est chaud. Idéalement, ceci est aussi spécifique que possible et il est simple de trouver une expérience à prouver ou à réfuter rapidement.
Il est souvent préférable de créer des expériences basées sur une simplification excessive du système testé. La raison pour laquelle les tests unitaires sont si puissants est qu'ils sont concentrés sur les tests pièce par pièce. lors des tests de performances, il est important de ne modifier qu'un facteur à la fois lors du test des prototypes. Les piles de prototypes qui semblent présenter des améliorations incrémentielles peuvent avoir des conséquences redoutables et sont généralement peu concluantes.
Au lieu de vous concentrer sur la rédaction d'un code correct et sans danger pour les threads, vous devez à ce stade vous concentrer sur les prototypes offrant les meilleurs gains de performances, quelle que soit leur exactitude. Si la suppression de la protection autour d'une structure de données procure un gain de performances considérable, il vaut probablement la peine d'optimiser cette structure de données ou de la sécuriser pour un accès multiple. Optimiser cette structure de données sans démontrer qu’elle est non performante a un coût élevé et une valeur peu claire.
Une fois qu'une expérience est effectuée, elle devrait soit appuyer soit contredire l'hypothèse. Souvent, de nombreuses hypothèses seront contredites avant qu'un goulot d'étranglement ne soit détecté. Finalement, il devrait être possible de réduire l'espace du problème à quelque chose de spécifique qui peut être amélioré. À ce stade, il est temps de passer du mode enquête à la mise en œuvre. Cela peut parfois être difficile car il s’agit d’un très gros changement de rythme et de style. De plus, ce qui doit changer peut facilement se trouver dans une partie du système où la familiarité peut être minimale ou inexistante. Encore une fois, cela montre pourquoi les prototypes sont une partie importante du processus. Une fois la solution créée, le processus est redémarré. en recommençant avec la collecte de nouvelles données de base.
Pour voir cette stratégie en action, consultez ce blog d'un autre membre de mon équipe: Améliorer l'efficacité de la serrure
Trucs et astuces
- Toute enquête est utile. Documentez les résultats négatifs pour éviter les doublons.
- Allez après les questions auxquelles on peut répondre rapidement
- Recueillez autant de données que possible
- Utiliser plusieurs sources de preuves
- Ayez confiance en vos outils ou reconstruisez-les jusqu'à ce que vous soyez
- Sérieusement collecter plus de données
- Utilisez des analyses comparatives micro et macro
- Assurez-vous que l’environnement que vous testez est constant d’un test à l’autre (à moins que ce delta ne soit le un facteur en train d'être testé)
- Lorsque vous formulez une hypothèse, il est souvent préférable d’en générer quelques-unes.
- S'il y a plus d'une hypothèse, ordonnez-les en utilisant la recherche heuristique de votre choix; Certains facteurs à prendre en compte sont l'estimation de la probabilité que l'hypothèse conduise à une performance améliorée et de la difficulté avec laquelle l'hypothèse sera testée.
Contactez-nous ici si vous souhaitez organiser une réunion ou demander une démonstration. Et Abonnez-vous à notre blog pour des meilleures pratiques et ressources plus utiles!
