Testy regresji po migracji

Testy regresji po migracji wykrywają zapytania, które zaczęły działać wolniej na nowej wersji silnika.

Co sprawdza się po zmianie silnika lub wersji systemu

Testy regresji po migracji służą do porównania zachowania aplikacji, zapytań i procesów przed oraz po przeniesieniu danych albo zmianie wersji używanego silnika. Ich celem nie jest wyłącznie potwierdzenie, że aplikacja uruchamia się bez błędu. Trzeba również sprawdzić, czy te same operacje zwracają poprawne wyniki, korzystają z właściwych tabel i kolumn oraz kończą się w akceptowalnym czasie. Migracja może zmienić sposób optymalizacji zapytań, wykorzystanie indeksów, interpretację typów danych albo kolejność wykonywania operacji, nawet jeśli kod aplikacji pozostał bez zmian.

Przed rozpoczęciem porównań przygotowuje się zestaw reprezentatywnych przypadków użycia. Powinny obejmować zapytania wykonywane często, operacje na dużych tabelach, filtrowanie po datach, sortowanie, łączenie wielu tabel oraz pobieranie stron wyników. Dla każdego przypadku warto zapisać parametry wejściowe, liczbę zwróconych rekordów, czas wykonania i wynik kontroli poprawności. Pomiar wykonany tylko raz może być przypadkowy, dlatego porównania należy przeprowadzać w podobnych warunkach, z uwzględnieniem rozgrzania pamięci podręcznej i aktualnego obciążenia systemu.

Porównanie planów wykonania i wyników zapytań

Najważniejszym elementem analizy jest zestawienie planu wykonania zapytania przed migracją z planem uzyskanym po migracji. Plan pokazuje między innymi, czy silnik wykonuje skan całej tabeli, korzysta z indeksu, wybiera złączenie zagnieżdżone czy przetwarza dane metodą złączenia haszującego. Sama zmiana planu nie oznacza jeszcze błędu, ponieważ nowy plan może być prawidłowy i szybszy dla aktualnego rozkładu danych. Niepokój powinno wzbudzić zwiększenie liczby odczytanych wierszy, przejście ze skanu indeksu do skanu tabeli, wielokrotny odczyt tej samej struktury lub wyraźny wzrost kosztu operacji.

Weryfikacja musi obejmować także treść wyników. Dwa zapytania mogą zwrócić tę samą liczbę rekordów, ale różnić się wartościami, kolejnością albo obsługą wartości pustych. Należy porównać klucze główne, sumy kontrolne wybranych kolumn, liczbę rekordów spełniających warunki oraz rezultaty agregacji. Szczególnej uwagi wymagają konwersje typów, porównania tekstów, strefy czasowe, zaokrąglenia liczb i sortowanie. Jeżeli migracja zmieniła kodowanie lub definicję kolumny, test powinien zawierać znaki diakrytyczne, wartości graniczne, długie teksty i wartości puste. Dopiero zgodność danych połączona z porównywalnym czasem wykonania potwierdza, że zapytanie przeszło regresję.

Pomiar spowolnień w warunkach zbliżonych do pracy

Testy wykonywane na małej kopii bazy często nie ujawniają problemów, które pojawiają się przy rzeczywistym wolumenie danych. Dlatego zestaw regresyjny powinien używać kopii o podobnej liczbie rekordów, strukturze indeksów i rozkładzie wartości. Jeżeli po migracji zmieniono schemat, trzeba sprawdzić także nowe indeksy, ograniczenia integralności oraz statystyki używane przez optymalizator. Nieprawidłowe albo nieaktualne statystyki mogą prowadzić do błędnej oceny liczby rekordów i wyboru nieefektywnego planu.

Pomiar warto powtórzyć dla kilku zestawów parametrów. Zapytanie może działać szybko dla wartości często występującej, a wolno dla wartości rzadkiej, albo odwrotnie. Należy rejestrować czas całkowity, czas oczekiwania na odczyt, liczbę operacji wejścia-wyjścia oraz zużycie pamięci, o ile dane narzędzie diagnostyczne je udostępnia. Przydatne jest również obciążenie równoległe, ponieważ pojedyncze zapytanie może przechodzić pomyślnie, natomiast wiele jednoczesnych żądań może powodować blokady lub kolejki. Wyniki powinny być przechowywane razem z wersją aplikacji, wersją silnika, datą testu, rozmiarem bazy i parametrami zapytań, aby później dało się odtworzyć pomiar.

Zakres naprawy po wykryciu regresji

Po znalezieniu spowolnienia nie należy od razu zmieniać zapytania bez ustalenia przyczyny. Najpierw trzeba potwierdzić, że pomiar jest powtarzalny i dotyczy tego samego przypadku. Następnie analizuje się plan wykonania, indeksy, statystyki, typy parametrów oraz różnice w schemacie. Przyczyną może być brak indeksu po migracji, zmiana selektywności danych, niejawna konwersja typu, inna kolejność złączeń albo użycie funkcji uniemożliwiającej efektywne filtrowanie. Każda korekta powinna być sprawdzona zarówno na zapytaniu problemowym, jak i na pozostałych przypadkach regresyjnych, ponieważ optymalizacja jednego wariantu może pogorszyć inny.

W środowisku domowym lub biurowym skutki migracji mogą być widoczne jako wolniejsze uruchamianie programu, dłuższe wyszukiwanie dokumentów, opóźnienia w synchronizacji albo zawieszanie interfejsu podczas pracy z lokalnym katalogiem danych. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy takich objawach można rozpocząć diagnostykę od sprawdzenia dysku, pamięci operacyjnej, obciążenia procesora, logów aplikacji oraz konfiguracji programu. Sama wymiana podzespołu nie rozwiąże problemu, jeśli źródłem opóźnień jest niepoprawny plan zapytania lub błąd w procesie migracji. Raport z testów powinien wskazywać konkretne zapytanie, zmierzoną różnicę, prawdopodobną przyczynę, zastosowaną zmianę i wynik ponownego pomiaru.