Liste définitive des étapes pour les tests de base de SQL Server?

Avant d'exécuter un test de performances / une ligne de base pour une application qui utilise SQL Server, je veux pouvoir définir l'instance sur un état "propre", sans redémarrer l'instance. Il y a des étapes que j'ai tendance à suivre, mais je veux construire une liste définitive qui est dans la séquence correcte et n'a pas d'étapes redondantes.

Cette liste d'étapes permet-elle de définir SQL Server sur un état «propre»?

La séquence est-elle logique / correcte?

Y a-t-il des étapes redondantes?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Eric Higgins
source

Pour info, le DROPCLEANBUFFERSest agréable à tester mais pas toujours précis. Si vous faites référence à une table à volume élevé, il est très probable que vous ayez presque toujours des pages en mémoire, et le temps d'E / S ne sera pas un facteur important dans cette requête. Vous pouvez placer plus de poids sur IO que ce qui est réaliste dans ce cas.

— JNK

Parlez-vous de tests dans un environnement de production ou un environnement de test isolé?

— bopapa_1979

Quiconque teste dans un environnement Prod doit être licencié. :) Oui, testez les environnements.

— Eric Higgins

Tout d'abord, je prendrais du recul et demanderais quelles mesures vous prévoyez de collecter pendant le test. Si vous comptez des lectures logiques par requête, par exemple, vous n'avez pas besoin de libérer le cache. Je suis un grand fan de l'utilisation des lectures logiques car cela est indépendant du fait que les données soient mises en cache ou sur disque - et en production, il est difficile de deviner si les données d'une requête seront mises en cache ou non (sauf si vous mettez en cache la base de données entière en mémoire) . Si vous réglez pour minimiser les lectures logiques, l'application ira plus vite, que les données soient en cache ou non.

Ensuite, je me demande ce qui change entre les exécutions. Par exemple, en exécutant EXEC SP_UPDATESTATS dans chaque base de données comme vous l'avez suggéré, vous allez rééchantillonner les statistiques des tables qui ont été mises à jour. Cependant, à moins que vous ne mettiez à jour les statistiques avec fullscan, vous obtenez des lignes aléatoires de la table - ce n'est pas trop répétable, et je ne pense pas que vous vouliez vraiment le faire. Au lieu de cela, vous souhaiterez peut-être restaurer les bases de données entre chaque exécution afin de toujours tester exactement les mêmes données. Si vos tests effectuent des insertions / mises à jour / suppressions, ils peuvent avoir des profils de performances différents à chaque exécution si vous ne restaurez pas la base de données (car ils ajoutent / modifient des données, ainsi que des statistiques changeantes sur les données) - et pire encore,

— Brent Ozar
source

Très bons points, l'objectif est d'avoir tout identique entre les runs. Les mesures que je prends dans ce cas @ hand sont des temps d'exécution pour des fonctions spécifiques dans une application (x secondes pour retourner la liste à l'application, y secondes pour ajouter un élément de file d'attente, etc.). Ce qui change entre les tests peut être des morceaux de code d'application et non des objets SQL, des objets SQL et non du code d'application, ou des paramètres de niveau d'instance / de base de données tels que la concurrence sans modification du code d'application. Si je devais ajouter une restauration hors de la porte avant chaque test, que pensez-vous de ma liste ci-dessus @ ce point? Suis-je en train de manquer quelque chose, ou la séquence a-t-elle besoin d'un peu de travail?

— Eric Higgins

Brent, tenez-vous compte du CPU dans vos tests?

— AK

@EricHiggins Plutôt que de tester plusieurs choses à la fois, je testerais les pièces individuellement. Je préfère tester directement les requêtes et voir quels changements ont un impact sur les performances. Par exemple, exécutez une trace SQL tout en exécutant des fonctions spécifiques dans l'application, puis continuez à relire cette trace tout en apportant des modifications d'index / de configuration pour améliorer les performances, et observez des choses comme les lectures logiques et les métriques du processeur dans les traces.

— Brent Ozar

@AlexKuznetsov Je ne suis pas celui qui fait les tests, en fait - Eric est celui qui a posé la question. Lorsque je fais ce genre de travail, je regarde les métriques du processeur au niveau de la requête ainsi que le serveur dans son ensemble.

— Brent Ozar

Nous utilisons un générateur de charge tiers (et avons une personne à temps plein dédiée au développement de tests de charge). Mes tests sont donc précis pour la transaction, la séquence, le nombre d'utilisateurs, les étapes exactes effectuées dans l'application ... tout. Je n'ai donc pas nécessairement besoin de regarder les métriques de type de tableau de bord SQL du tout. Le logiciel de test de charge suit les temps de réponse des modules d'application à la milliseconde. Faire une restauration DB est donc une bonne idée. Je dois vérifier les autres étapes que je fais pour être sûr que j'accomplis cet état de "table rase" que je recherche avant chaque cycle de test.

— Eric Higgins