Comment suivre les tests de performance

Question

Je teste actuellement les performances et la charge d'un système complexe à plusieurs niveaux, qui étudie les effets de différents changements, mais je ne parviens pas à tout contrôler:

• Il existe de nombreuses copies de différents assemblages .
  • Assemblages libérés oralement
  • Correctifs officiellement publiés
  • Les assemblages que j'ai construits contenant d'autres correctifs supplémentaires
  • Assemblages que j'ai construits contenant une journalisation ou un suivi de diagnostic supplémentaire
• Il existe de nombreux correctifs de base de données , certains des assemblys ci-dessus dépendent de l'application de certains correctifs de base de données
• Il existe plusieurs niveaux de journalisation , à différents niveaux (journalisation des applications, statistiques de performances des applications, profilage du serveur SQL)
• Il existe de nombreux scénarios différents , il est parfois utile de ne tester qu'un seul scénario, d'autres fois, je dois tester des combinaisons de différents scénarios.
• La charge peut être répartie sur plusieurs machines ou sur une seule machine
.
• Les données présentes dans la base de données peuvent changer , par exemple, certains tests peuvent être effectués avec les données générées, puis ultérieurement avec des données provenant d'un système en direct.
• Il existe une quantité énorme de données de performances potentielles à collecter après chaque test , par exemple:
  • De nombreux types de journalisation spécifiques à une application
  • traces du profileur SQL
  • Journaux des événements
  • DMV
  • compteurs Perfmon
• La ou les bases de données ont une taille de plusieurs Go ; ainsi, lorsque j'aurais utilisé des sauvegardes pour revenir à un état antérieur, j'ai tendance à appliquer des modifications à la base de données présente après le dernier test. perdre rapidement le fil des choses.

Je collecte autant d'informations que possible sur chaque test que je fais (scénario testé, quels correctifs sont appliqués et quelles données figurent dans la base de données), mais je suis toujours obligé de répéter les tests à cause de résultats incohérents. Par exemple, je viens de faire un test que je croyais être une copie exacte d'un test que j'avais effectué il y a quelques mois, mais avec des données mises à jour dans la base de données. Je sais pertinemment que les nouvelles données devraient entraîner une dégradation des performances, mais les résultats montrent le contraire!

En même temps, je me trouve à perdre un temps démesuré à enregistrer tous ces détails.

J'ai envisagé d'utiliser des scripts pour automatiser la collecte de données de performances, etc., mais je n'étais pas sûr que ce soit une si bonne idée. Non seulement le temps passé à développer des scripts plutôt que les tests, mais des bugs dans mes scripts. pourrait me faire perdre le fil des choses encore plus rapidement.

Je cherche quelques conseils / astuces pour mieux gérer l'environnement de test, en particulier pour trouver un équilibre entre collecter tout et effectuer des tests au risque de rater quelque chose d'important. ?

Answer 1

Scripter la collection des paramètres de test + environnement est une très bonne idée à vérifier. Si vous effectuez des tests sur plusieurs jours et que le script prend une journée, c'est du temps bien dépensé. Si, après une journée, vous voyez que cela ne va pas finir bientôt, réévaluez et éventuellement arrêtez de poursuivre dans cette direction.

Mais vous vous devez de l'essayer.

Answer 2

J'aurais tendance à être d'accord avec @orip, écrire au moins une partie de votre charge de travail vous permettra probablement de gagner du temps. Vous pourriez envisager de prendre un moment pour demander quelles tâches prennent le plus de temps en termes de travail et dans quelle mesure sont-elles soumises à l'automatisation? Les scripts sont particulièrement efficaces pour la collecte et la synthèse de données - bien mieux que les utilisateurs, généralement. Si les données de performance requièrent beaucoup d’interprétation de votre part, vous pourriez avoir des problèmes.

Un avantage de la création de scripts pour certaines de ces tâches est que vous pouvez les archiver aux côtés de la source / des correctifs / des branches et que vous pouvez tirer parti de la structure organisationnelle de la complexité de vos systèmes plutôt que de lutter pour la poursuivre comme vous le faites maintenant. .

Answer 3

Si vous pouvez vous contenter de tester uniquement quelques configurations définies, cela simplifiera la tâche de l'administrateur. Il peut également être plus facile d’en installer une sur chacune des machines virtuelles, qui peut être rapidement redéployée pour donner des lignes de base propres.

Si vous avez réellement besoin de la complexité que vous décrivez, nous vous recommandons de créer une base de données simple vous permettant d’interroger les résultats à plusieurs variables que vous avez. Le fait d’avoir une colonne pour chacun des facteurs importants vous permettra d’interroger des questions telles que "quelle configuration de test présentait la plus faible variance de temps de latence?" et "quelle base de données de tests a permis de soulever la plupart des bogues?". J'utilise sqlite3 (probablement via l'encapsuleur Python ou le plug-in Firefox) pour ce type de collection légère, car elle réduit les coûts de maintenance et vous évite de trop perturber le système testé, même si vous devez exécuter une exécution. la même boîte.

La création de scripts pour les tests les rend plus rapides à exécuter et permet de rassembler les résultats selon un ordre déjà défini, mais il semble que votre système soit trop complexe pour que cela soit facile à effectuer.