Zmierz konkretne zadanie
Stwierdzenie „program działa wolno” może oznaczać długie logowanie, opóźnione wyszukiwanie albo zapis formularza. Każdy z tych problemów ma inny przebieg. Wybierz zadanie, określ dane i zapisz, gdzie mija czas: przed odpowiedzią serwera, podczas zapytania do bazy czy przy rysowaniu widoku w przeglądarce. Bez takiego rozdzielenia łatwo poprawiać element, który nie jest rzeczywistym ograniczeniem.
W przykładowym CRM lista klientów ładuje się szybko dla nowego konta, ale wolno u kierownika widzącego cały zespół. To cenna wskazówka: zakres danych wpływa na zachowanie. Test na pustej bazie nie odtworzy problemu. Przygotuj bezpieczną próbkę reprezentującą liczbę spraw, długość historii i sposób filtrowania występujący w codziennej pracy.
Sprawdź liczbę zapytań, nie tylko ich czas
Widok stu klientów może wykonać jedno zapytanie do listy i kolejne dla ostatniej rozmowy każdej osoby. Ten wzorzec mnoży pracę wraz z liczbą rekordów. Zanim dodasz pamięć podręczną, sprawdź, czy dane da się pobrać zbiorczo albo czy wszystkie są potrzebne na pierwszym ekranie. Szczegółową historię można często otworzyć dopiero po wyborze konkretnej sprawy.
Narzędzia diagnostyczne powinny pokazywać strukturę zapytań bez ujawniania pełnych danych klientów. W PostgreSQL polecenie EXPLAIN przedstawia plan wykonania, a jego wariant ANALYZE wykonuje zapytanie i pokazuje pomiary. Przy operacjach modyfikujących trzeba uwzględnić ten skutek; nie należy uruchamiać ich eksperymentalnie na produkcji bez odpowiedniego zabezpieczenia.
Dopasuj indeks do rzeczywistego filtra
Indeks może pomagać w odczycie, ale nie jest bezpłatnym przyspieszeniem każdej operacji. Zajmuje miejsce i wymaga utrzymania przy zmianach danych. Dobieraj go do używanych warunków, porządku sortowania i rozkładu wartości. Lista aktywnych spraw jednego opiekuna ma inny wzorzec niż wyszukiwanie konkretnego numeru zlecenia.
Nie oceniaj indeksu wyłącznie po jego obecności. Sprawdź plan i pomiar na reprezentatywnych danych. Dla małej tabeli zwykły odczyt całości może być rozsądnym wyborem silnika. Celem jest skrócenie konkretnego zadania, a nie wymuszenie każdego zapytania przez indeks albo uzyskanie atrakcyjnego zrzutu ekranu z narzędzia diagnostycznego.
Ogranicz ilość danych wysyłanych do widoku
Pobieranie całej bazy do przeglądarki tylko po to, aby pokazać pierwszych dwadzieścia wierszy, zwiększa transfer i pracę urządzenia. Zastosuj stronicowanie po stronie serwera oraz ustal stabilny porządek. Przy często zmieniających się listach rozważ przechodzenie od ostatniego znanego klucza zamiast coraz większego przesunięcia. Wybór zależy od potrzeb nawigacji i modelu danych.
MyTworzymy.pl obsługuje firmy z całej Polski i może być partnerem przy rozwoju programu dopasowanego do rzeczywistej pracy zespołu. W zgłoszeniu problemu warto podać konkretny widok, filtr i orientacyjny zakres danych. To bardziej użyteczna podstawa rozmowy niż oczekiwanie, że sam nowy wygląd panelu usunie opóźnienia zapytań.
Pamięć podręczna wymaga zasad aktualności
Warto buforować kosztowny raport, który nie musi zmieniać się co sekundę. Trzeba jednak określić, kto może zobaczyć wynik, z jakiego zakresu danych powstał i kiedy traci ważność. Wspólny klucz cache dla użytkowników o różnych uprawnieniach może ujawnić informacje. Przy projektowaniu bufora nie wolno zapomnieć o granicach dostępu obowiązujących w zwykłym zapytaniu.
Przy danych wymagających natychmiastowej aktualności lepiej najpierw usprawnić odczyt niż maskować problem długim cache. Użytkownik zmieniający status sprawy powinien rozumieć, kiedy zobaczy nową wartość. Jeżeli raport jest odświeżany okresowo, pokaż czas jego przygotowania. Opóźnione dane mogą być użyteczne, o ile nie udają informacji bieżącej.
Przenieś długie operacje do kontrolowanych zadań
Eksport wielu rekordów nie musi blokować interfejsu do czasu zakończenia. Program może utworzyć zadanie, pokazać jego stan i udostępnić wynik uprawnionej osobie po przygotowaniu. Potrzebne są limity, możliwość rozpoznania błędu i termin usunięcia pliku. Nie wystarczy wysłać operacji w tło bez sposobu sprawdzenia, czy nadal działa.
Z MyTworzymy.pl warto omawiać wydajność jako część użyteczności programu, obejmującą również raporty, importy i pracę kilku osób naraz. Dla przedsiębiorstwa prowadzącego obsługę ogólnopolską istotne może być stabilne działanie pod koniec dnia, gdy zespół równocześnie zamyka sprawy. Właśnie taki scenariusz powinien znaleźć się w testach, nie tylko pojedyncze otwarcie panelu.
Porównaj wynik i sprawdź skutki uboczne
Po zmianie powtórz ten sam scenariusz z podobnymi danymi. Oglądaj nie tylko średni czas, ale także wolniejsze próby i zachowanie pod równoczesnym obciążeniem. Sprawdź, czy przyspieszenie odczytu nie pogorszyło zapisu lub nie ujawniło danych innego użytkownika. Zapisz warunki pomiaru, aby później nie porównywać wyniku z pustej bazy z obciążoną produkcją.
Jeżeli baza jest szybka, wróć do serwera aplikacji, sieci i przeglądarki. Duża tabela, ciężkie elementy interfejsu albo blokująca integracja mogą dominować nad czasem SQL. Diagnoza kończy się dopiero wtedy, gdy da się wyjaśnić poprawę konkretnego zadania. Większy serwer jest czasem uzasadniony, ale nie powinien zastępować informacji, na co program zużywa dostępne zasoby.
Wprowadź niewielki test regresji wydajności na danych syntetycznych. Nie musi naśladować każdego dnia pracy, lecz powinien wykrywać powrót dodatkowych zapytań i nieograniczonego pobierania listy. W ten sposób kolejna funkcja nie cofnie wcześniejszej poprawki niezauważenie, a zespół będzie miał punkt odniesienia przed następnym wdrożeniem.