Kategorie i listingi
Sprawdzamy liczbę operacji wykonywanych przy generowaniu list produktów, cen, atrybutów i filtrów.
Optymalizacja wydajności Magento
Sklep się długo wczytuje. Wyszukiwanie i panel administracyjny działają coraz wolniej. Kolejne poprawki dają chwilową zmianę, ale po pewnym czasie problem wraca.
W takiej sytuacji nie zaczynamy od przypadkowego „przyspieszania Magento”. Najpierw mierzymy platformę i ustalamy, gdzie rzeczywiście znajduje się wąskie gardło.
Dopiero potem decydujemy, co warto optymalizować.
Bezpłatna rozmowa, 30-60 minut. Omówimy objawy, dostępne pomiary i architekturę platformy. Wstępnie określimy, od jakich danych i testów warto rozpocząć diagnostykę.
Diagnoza
Wolny sklep jest objawem
W Magento widoczny problem nie zawsze pokazuje jego przyczynę.
Wolna kategoria może wynikać z zapytania do bazy, sposobu pobierania atrybutów, zewnętrznego modułu albo indeksowania. Wolne wyszukiwanie może mieć źródło w konfiguracji OpenSearch, ale równie dobrze w modelu danych lub sposobie budowania zapytań.
Dołożenie cache albo zwiększenie zasobów serwera może na chwilę zmniejszyć objawy, ale nie musi rozwiązać źródła problemu.
Dlatego zaczynamy od diagnozy, a nie od gotowej listy zmian.
Zakres analizy
Co diagnozujemy
Najczęściej analizujemy kilka obszarów jednocześnie.
Karty produktów
Analizujemy koszt pobierania atrybutów, produktów powiązanych oraz dodatkowych modułów wykonywanych przy każdym requestcie.
Wyszukiwanie i OpenSearch
Weryfikujemy strukturę indeksów, sposób budowania zapytań i zakres danych przetwarzanych przez wyszukiwarkę.
Baza danych i SQL
Szukamy kosztownych oraz powtarzających się zapytań i operacji wykonywanych częściej, niż jest to potrzebne.
Cache
Sprawdzamy konfigurację i to, czy cache faktycznie ogranicza koszt pracy aplikacji.
Infrastruktura
Analizujemy, czy środowisko jest dobrze dopasowane do sposobu działania konkretnej platformy.
Frontend również jest częścią analizy. Jeśli to on okaże się głównym ograniczeniem, nie będziemy szukać problemu na siłę w backendzie.
Jak pracujemy
Jak pracujemy
-
01
Diagnoza
Zaczynamy od diagnozy i profilowania.
-
02
Priorytety
Na tej podstawie ustalamy priorytety - nie wszystko trzeba zmieniać jednocześnie. W pierwszej kolejności zajmujemy się obszarami, które dają największy efekt w stosunku do kosztu i ryzyka.
-
03
Zmiany
Zmiany wprowadzamy etapami i mierzymy rezultat po ważniejszych modyfikacjach.
-
04
Decyzja
Jeżeli po analizie okaże się, że dalsze optymalizowanie danego obszaru nie ma ekonomicznego sensu, mówimy o tym i proponujemy inne podejście.
Profilowanie
Pomiary mają odpowiedzieć na konkretne pytanie
Profilujemy platformę po to, żeby ustalić, gdzie rzeczywiście tracony jest czas, a następnie zweryfikować, czy zmiana coś poprawiła.
Porównujemy pomiary w możliwie podobnych warunkach.
Nie każdy wynik musi później stać się formalnym raportem dla klienta. Część profilowania jest po prostu narzędziem pracy zespołu.
W dużych platformach optymalizacja często nie kończy się jednym projektem. Katalog, kod i integracje stale się zmieniają, dlatego wąskie gardło może z czasem pojawić się w innym miejscu.
Przykłady optymalizacji
Kategorie i listingi
zapytania SQL
- Przed
- 652
- Po
- 99
czas backendu
- Przed
- 2,69 s
- Po
- 0,787 s
wykorzystanie CPU
−65%
W jednym z profilowanych projektów pojedyncze wygenerowanie kategorii wykonywało 652 zapytania SQL. Po zmianach liczba ta spadła do 99, czyli o około 85%.
W tym samym porównaniu czas backendowego generowania kategorii zmniejszył się z 2,69 s do 0,787 s, czyli o około 71%, a wykorzystanie CPU spadło o około 65%.
Zmiany obejmowały między innymi optymalizację zapytań, sposobu indeksowania i działania dodatkowych modułów.
Karty produktów
Karta produktu może wykonywać dużą liczbę kosztownych operacji, szczególnie przy rozbudowanych atrybutach, rekomendacjach i produktach powiązanych.
W kolejnych profilach tego samego projektu uzyskaliśmy:
krótszy czas backendowego generowania karty produktu
do 62%
mniej operacji I/O
do 71%
mniej czasu CPU
do 54%
zapytania SQL
- Przed
- 373
- Po
- 151
Optymalizacje dotyczyły między innymi sposobu pobierania atrybutów, produktów powiązanych, modułów zewnętrznych oraz wykorzystania OpenSearch.
Co te liczby znaczą - i czego nie znaczą
Szybsze wykonanie backendu oznacza mniej pracy potrzebnej do obsłużenia pojedynczego requestu i może pozostawić platformie większy zapas zasobów przy rosnącym obciążeniu.
Nie oznacza jednak automatycznie lepszego Core Web Vitals, wyższej pozycji w Google ani większej sprzedaży.
Na doświadczenie użytkownika wpływa również frontend, obrazy, skrypty zewnętrzne, CDN, sieć i samo urządzenie.
Nie używamy wyników profilowania backendu jako dowodu wzrostu konwersji.
Są to wyniki porównywalnego, technicznego profilowania backendu bez FPC i OPcache. Nie przedstawiają średnich czasów odpowiedzi produkcyjnej ani wyników Core Web Vitals i nie stanowią deklaracji poprawy pozycji SEO, konwersji czy konkretnego wyniku PageSpeed.
Dane i wyszukiwanie
Wyszukiwanie i OpenSearch
OpenSearch odpowiada nie tylko za pole wyszukiwania. Przy dużych katalogach jest również istotnym elementem filtrowania i pracy z danymi katalogowymi.
Analizujemy sposób indeksowania oraz zapytania wykonywane do wyszukiwarki.
Czasem bardziej efektywne jest przeniesienie określonych odczytów z relacyjnej bazy danych do odpowiednio przygotowanego indeksu. Nie jest to jednak uniwersalna recepta - decyzja wynika z pomiarów i sposobu wykorzystania danych.
Baza danych i SQL
Problemy z bazą mogą być długo niewidoczne, szczególnie jeśli część kosztownych operacji przykrywa cache.
Sprawdzamy, które zapytania trwają najdłużej, które wykonywane są wielokrotnie i czy moduły nie pobierają większej ilości danych, niż rzeczywiście potrzebują.
Czasami niewielka zmiana sposobu pobierania danych daje większy efekt niż zwiększenie zasobów infrastruktury.
Środowisko
Cache i infrastruktura
Redis, Varnish, PHP, baza danych i konfiguracja środowiska mają bezpośredni wpływ na zachowanie Magento.
Cache jest potrzebny, ale nie powinien służyć wyłącznie do ukrywania kosztownego kodu.
Jeżeli diagnoza pokaże, że problem rzeczywiście leży w infrastrukturze, możemy również pomóc w jej zmianie lub optymalizacji.
Frontend
Co z frontendem?
Ta usługa koncentruje się przede wszystkim na backendzie, danych i infrastrukturze, ale nie ignorujemy frontendu.
W nowych wdrożeniach domyślnie pracujemy z Hyvä. Przy starszym sklepie istniejący frontend może jednak sam być znaczącym źródłem problemów.
Jeżeli backend generuje odpowiedź szybko, a sklep nadal jest ciężki po stronie użytkownika, właściwym kierunkiem może być przebudowa warstwy prezentacji.
W takim przypadku rekomendujemy Hyvä dla Magento → , zamiast próbować rozwiązać frontendowy problem zmianami w bazie czy cache.
Dopasowanie
Kiedy potrzebna jest inna usługa
Duże katalogi w Magento
Jeżeli problem narasta przede wszystkim wraz ze wzrostem katalogu i wynika z modelu danych, indeksowania lub sposobu pracy z dużą liczbą wartości, właściwszym punktem wyjścia może być analiza dużego katalogu Magento.
duże katalogi w Magento →Hyvä dla Magento
Jeśli backend jest szybki, a problem znajduje się w warstwie frontendowej, rozwiązaniem może być przebudowa warstwy prezentacji z wykorzystaniem Hyvä.
Hyvä dla Magento →Przejęcie i stabilizacja Magento
Jeżeli platforma jest ogólnie niestabilna, błędy wracają i trudno określić stan techniczny projektu, warto zacząć od przejęcia i stabilizacji projektu.
przejęcia i stabilizacji Magento →Pytania
FAQ
VLCT
Nie da się odpowiedzialnie podać jednej wartości bez diagnozy. W jednym z naszych projektów czas backendowego generowania kategorii spadł z 2,69 s do 0,787 s, ale jest to wynik konkretnej platformy i konkretnego zakresu zmian.
VLCT
Może pomóc, jeśli problemem jest czas odpowiedzi backendu, ale Core Web Vitals zależą również od frontendu, zasobów, sposobu renderowania i skryptów zewnętrznych. Dlatego najpierw trzeba ustalić, która warstwa jest rzeczywistym ograniczeniem.
VLCT
Tylko wtedy, gdy istotna część problemu leży we frontendzie. Hyvä nie naprawia wolnej bazy danych, problemów z OpenSearch, integracjami czy indeksowaniem.
VLCT
Nie zawsze. Mocniejsza infrastruktura może pomóc, jeśli obecne zasoby są ograniczeniem, ale nie naprawi nieefektywnego kodu lub modelu danych. Najpierw sprawdzamy, gdzie faktycznie tracone są zasoby.
VLCT
Zakres dokumentacji zależy od projektu. Pomiary wykonujemy, żeby podejmować decyzje i weryfikować zmiany. Nie wszystkie muszą być osobnym formalnym deliverable.
VLCT
Może być trwały dla usuniętego problemu, ale platforma nadal się zmienia. Dochodzą nowe moduły, integracje i dane. Dlatego przy większych systemach wydajność warto monitorować również w ramach dalszego utrzymania.