Panel filtrów, który odpowiada po czterech sekundach, jest odbierany jako zepsuty. Problem rzadko leży w samym module: wynika ze sposobu budowania zapytań i z tego, co baza musi przejść, by na nie odpowiedzieć.
Oto jak zlokalizować przyczynę, zanim cokolwiek zmienicie.
Mierzyć zamiast zakładać
Trzy pomiary, w tej kolejności.
Rzeczywisty czas odpowiedzi żądania filtrowania, zmierzony w zakładce sieci przeglądarki na waszej największej kategorii z dwoma lub trzema aktywnymi filtrami. Zanotujcie wartość: to wasz punkt wyjścia.
Udział tego czasu spędzony w bazie danych. Włączcie profilowanie PrestaShop w środowisku testowym: pokazuje liczbę wykonanych zapytań i ich skumulowany czas. Jeśli czas bazy stanowi 80 % całości, nie ma sensu patrzeć gdzie indziej.
Liczba wykonanych zapytań. To często objawienie: filtrowana strona kategorii wykonująca trzysta zapytań ma problem projektowy, nie problem mocy serwera.
Ten trzeci punkt zasługuje na uwagę. Mnożenie się zapytań zwykle sygnalizuje obliczanie liczników wartość po wartości albo ładowanie produktów jeden po drugim w pętli.
Cztery główne przyczyny
Złączenia na tabelach atrybutów. Filtrowanie po trzech atrybutach oznacza wielokrotne łączenie tabel wartości. Na katalogu dwudziestu tysięcy wariantów te złączenia produkują znaczne zbiory pośrednie.
Obliczanie liczników. Wyświetlanie liczby wyników przy każdej wartości oznacza agregację na wartość. Na panelu z sześćdziesięcioma wartościami to może być sześćdziesiąt agregacji przy każdej zmianie selekcji.
Liczenie całości dla paginacji. Policzenie wierszy szerokiej selekcji kosztuje prawie tyle, co ich odczytanie.
Brakujące indeksy. Na tabelach łączących produkty, atrybuty i kategorie brak indeksu zamienia wyszukiwanie w pełne skanowanie tabeli.
Diagnoza indeksów
To najbardziej opłacalna i najszybsza weryfikacja.
Pobierzcie najwolniejsze zapytanie filtrujące z dziennika wolnych zapytań waszej bazy, a następnie wykonajcie je poprzedzone słowem kluczowym planu wykonania.
Trzy sygnały do wypatrzenia w wyniku.
Typ dostępu wskazujący pełne skanowanie na dużej tabeli. To znak brakującego lub bezużytecznego indeksu.
Liczba przejrzanych wierszy bez żadnej proporcji do liczby wierszy zwróconych. Przejrzenie dwustu tysięcy wierszy, by zwrócić czterdzieści, wskazuje, że filtrowanie odbywa się po odczycie, a nie przez indeks.
Wzmianka o sortowaniu tymczasowym lub tabeli tymczasowej, która sygnalizuje, że baza nie może zrealizować sortowania przez indeks i musi zmaterializować wynik pośredni.
Punkt praktyczny: użyteczne indeksy na tych tabelach często obejmują kolumny łączone, a ich kolejność ma znaczenie. Indeks na produkt, potem atrybut nie obsługuje tych samych zapytań co indeks na atrybut, potem produkt.
Filtry Fasetowe AJAX do PrestaShopNawigacja fasetowa, która filtruje szybko i indeksuje rozsądnie€99,00
Zmniejszyć pracę zamiast ją przyspieszać
Przed optymalizacją techniczną trzy decyzje funkcjonalne mają często większy efekt.
Zmniejszyć liczbę filtrów. Każdy filtrowany atrybut dodaje potencjalne złączenia i liczniki do obliczenia. Dwanaście filtrów, z których używane są cztery, kosztuje trzy razy za dużo.
Zrezygnować z liczników na dużych katalogach albo liczyć je tylko na najczęściej używanych filtrach. Utracony komfort jest realny, zysk czasu też.
Ograniczyć głębokość kombinacji. Powyżej trzech jednoczesnych filtrów selekcje stają się rzadkie i kosztowne. Możecie nałożyć limit i nikt tego nie zauważy.
Te trzy środki nie wymagają żadnego developmentu i testuje się je w jedno popołudnie.
Indeks dedykowany
Gdy poprzednie środki nie wystarczają, odpowiedź strukturalna polega na tym, by nie odpytywać już tabel katalogu w momencie filtrowania.
Zasada: płaska, wstępnie obliczona tabela zawierająca dla każdego produktu jego filtrowane wartości, cenę, dostępność i kategorie. Filtrowanie staje się prostym zapytaniem na jednej zindeksowanej tabeli.
Trzy punkty wdrożenia.
Aktualizacja musi się wyzwalać przy każdej zmianie produktu, ceny lub stanu magazynowego. Zdesynchronizowany indeks pokazuje produkty, które już nie istnieją, albo ukrywa nowości.
Pełna przebudowa musi pozostać możliwa, a jej czas wykonania zmierzony: na dużym katalogu może zająć kilka minut i nie może się wykonywać w godzinach szczytu.
Wyzwalanie masowe. Import katalogu zmieniający dziesięć tysięcy produktów nie może wyzwolić dziesięciu tysięcy jednostkowych przebudów. Przewidźcie tryb odłożony.
Cache i jego granice
Cache jest użyteczny i często źle stosowany w tym temacie.
Cache’owanie wyników filtrowania działa dobrze, gdy żądane kombinacje są nieliczne i powtarzalne. Tak jest w większości sklepów: kilkadziesiąt kombinacji pokrywa zasadniczą część ruchu.
Dwie granice do poznania. Cache nie obsługuje pierwszej wizyty każdej kombinacji, która pozostaje wolna. I musi być unieważniany przy każdej zmianie stanu lub ceny, inaczej pokazujecie fałszywe informacje.
Przy danych o dostępności czas cache musi pozostać krótki, kilka minut, co mocno ogranicza jego sens. Częste podejście polega na cache’owaniu listy pasujących produktów i pobieraniu ceny i stanu na żywo.
Weryfikacje po stronie infrastruktury
Trzy punkty, które nie dotyczą kodu.
Pamięć przydzielona bazie. Baza, która nie może trzymać indeksów w pamięci, odczytuje je z dysku przy każdym zapytaniu. To najczęstsza przyczyna ogólnej powolności po wzroście katalogu.
Konfiguracja cache zapytań i buforów, do dostosowania według rzeczywistego rozmiaru danych, zamiast pozostawać na wartościach domyślnych instalacji.
Zasoby konkurujące. Eksport katalogu lub zaplanowane zadanie wykonujące się równocześnie ze szczytem ruchu degraduje wszystko. Przesuńcie to, co da się przesunąć.
Pełne postępowanie
Sześć etapów, w tej kolejności malejącej opłacalności.
1. Zmierzcie czas odpowiedzi i liczbę zapytań.
2. Sprawdźcie indeksy planem wykonania na najwolniejszym zapytaniu.
3. Ograniczcie proponowane filtry do faktycznie używanych.
4. Wyłączcie lub ograniczcie liczniki, jeśli katalog jest duży.
5. Wdróżcie cache na częstych kombinacjach.
6. Rozważcie indeks dedykowany, jeśli pięć pierwszych etapów nie wystarczy.
Punkt metodyczny: mierzcie po każdym etapie. Przeskoczenie kilku etapów naraz pozbawia was wiedzy, który z nich dał efekt, a więc wiedzy, gdzie skoncentrować wysiłek następnym razem.
Moduł Filtrów Fasetowych AJAX dla PrestaShop integruje te mechanizmy w PrestaShop 8 i 9: dedykowany, wstępnie obliczony indeks z aktualizacją przyrostową, liczniki wyników w pojedynczej agregacji, cache na kombinację z unieważnianiem przy zmianach stanu i ceny oraz konfigurowalne ograniczenie głębokości kombinacji.
