Ostateczna lista kroków testowania linii bazowej programu SQL Server?

Przed uruchomieniem testu wydajności / linii bazowej dla aplikacji korzystającej z programu SQL Server chcę ustawić instancję w stanie „czystym” bez ponownego uruchamiania instancji. Są kroki, które zwykle wykonuję, ale chcę zbudować ostateczną listę, która ma prawidłową kolejność i nie zawiera zbędnych kroków.

Czy ta lista kroków umożliwia ustawienie programu SQL Server w stan „czysty”?

Czy sekwencja jest logiczna / poprawna?

Czy są jakieś zbędne kroki?

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
źródło

FYI, DROPCLEANBUFFERSjest miły do testowania, ale nie zawsze dokładny. Jeśli odwołujesz się do tabeli o dużej objętości, jest bardzo prawdopodobne, że prawie zawsze będziesz mieć strony w pamięci, a czas IO nie będzie dużym czynnikiem w tym zapytaniu. W takim przypadku możesz kłaść większy nacisk na IO niż jest to realistyczne.

— JNK,

Czy mówisz o testowaniu w środowisku produkcyjnym czy izolowanym środowisku testowym?

— bopapa_1979

Każdy, kto testuje w środowisku Prod, powinien zostać zwolniony. :) Tak, środowiska testowe.

— Eric Higgins,

Najpierw cofnę się i zapytam, jakie pomiary planujesz zebrać podczas testu. Jeśli na przykład liczysz logiczne odczyty według zapytania, nie musisz zwalniać pamięci podręcznej. Jestem wielkim fanem korzystania z odczytów logicznych, ponieważ jest to niezależne od tego, czy dane są buforowane, czy na dysku - a podczas produkcji trudno zgadnąć, czy dane zapytania będą buforowane, czy nie (chyba że buforujesz całą bazę danych w pamięci) . Jeśli dostroisz się, aby zminimalizować odczyty logiczne, aplikacja będzie działać szybciej, niezależnie od tego, czy dane są w pamięci podręcznej, czy nie.

Następnie zapytałbym, co się zmienia między biegami. Na przykład, uruchamiając EXEC SP_UPDATESTATS w każdej bazie danych, jak zasugerowałeś, zamierzasz ponownie próbkować statystyki tabel, które zostały zaktualizowane. Jednak, chyba że aktualizujesz statystyki za pomocą fullscan, otrzymujesz losowe wiersze z tabeli - to nie jest zbyt powtarzalne i nie sądzę, że naprawdę chcesz to zrobić. Zamiast tego możesz przywrócić bazy danych między każdym uruchomieniem, aby zawsze testować dokładnie te same dane. Jeśli Twoje testy wykonują operacje wstawiania / aktualizacji / usuwania, mogą mieć różne profile wydajności przy każdym uruchomieniu, jeśli nie przywracasz bazy danych (ponieważ dodają / zmieniają dane oraz zmieniają statystyki danych) - a nawet gorzej,

— Brent Ozar
źródło

Bardzo dobre punkty, celem jest, aby wszystko było identyczne między biegami. Pomiary, które wykonuję w tym przypadku @ ręcznie, to czasy działania określonych funkcji w aplikacji (x sekund, aby powrócić do listy aplikacji, y sekund, aby dodać element kolejki itp.). To, co zmienia się między testami, może obejmować fragmenty kodu aplikacji, a nie obiekty SQL, obiekty SQL, a nie kod aplikacji, lub ustawienia poziomu instancji / DB, takie jak współbieżność bez zmian w kodzie aplikacji. Gdybym miał dodać przywrócenie z bramki przed każdym testem, co sądzisz o mojej liście powyżej @ tego punktu? Czy coś mi brakuje, czy sekwencja wymaga trochę pracy?

— Eric Higgins

Brent, bierzesz pod uwagę procesor podczas testowania?

— AK

@EricHiggins Zamiast testować wiele rzeczy naraz, testowałbym je osobno. Wolę testować zapytania bezpośrednio i sprawdzać, jakie zmiany wpływają na wydajność. Na przykład uruchom śledzenie SQL podczas wykonywania określonych funkcji w aplikacji, a następnie kontynuuj odtwarzanie tego śladu, wprowadzając zmiany indeksu / konfiguracji w celu poprawy wydajności, i obserwuj takie rzeczy, jak logiczne odczyty i pomiary procesora w śladach.

— Brent Ozar

@AlexKuznetsov Właściwie to nie ja przeprowadzam testy - to Eric zadał to pytanie. Kiedy wykonuję ten rodzaj pracy, patrzę na dane procesora na poziomie zapytania, a także na cały serwer.

— Brent Ozar

Korzystamy z zewnętrznego generatora obciążenia (i mamy pełnoetatową osobę zajmującą się opracowywaniem testów obciążenia). Więc moje testy są dokładne dla transakcji, sekwencji, liczby użytkowników, dokładnych kroków wykonanych w aplikacji ... wszystko. Więc niekoniecznie muszę w ogóle patrzeć na metryki typu panelu kontrolnego SQL. Oprogramowanie do testowania obciążenia śledzi czasy reakcji modułów aplikacji na milisekundę. Dlatego przywracanie bazy danych jest dobrym pomysłem. Muszę sprawdzić poczytalność innych kroków, które robię, aby upewnić się, że osiągam stan „Wyczyść konto”, którego szukam przed każdą rundą testów.

— Eric Higgins