Wysoka wydajność Magento – jak w prosty sposób obsłużyć 8000 zamówień dziennie przy pomocy Adobe Commerce

Z poniższego artykułu dowiesz się:

• jakie działania są potrzebne, by upewnić się, że Adobe Commerce poradzi sobie z obciążeniem;
• jakie działania są potrzebne od strony hostingu/chmury, aby obsłużyć tak wiele zamówień;
• jakie pytania musisz zadać zespołowi programistów, aby upewnić się, że jest odpowiednio przygotowany
• na jakie pytania musi odpowiedzieć zespół odpowiedzialny za biznes, aby upewnić się, że Twoja firma jest odpowiednio przygotowana.

Jaka jest różnica między Magento a Adobe Commerce (i Adobe Commerce Cloud)?

Najpierw przyjrzyjmy się kilku kluczowym różnicom między tymi – na pierwszy rzut oka identycznymi – platformami. Adobe Commerce to licencjonowana wersja Magento 2, która zawiera wszystkie podstawowe elementy. Ponadto, oprogramowanie Adobe Commerce wprowadza kilka nowych funkcji, takich jak pełna obsługa B2B, program lojalnościowy, planowanie treści, segmentacja itd. – ale to tylko dodatkowe funkcje. Jeśli przyjrzysz się dokładniej, zauważysz, że jest też kilka innych, nie tak oczywistych różnic.

Pierwszą z nich jest zmiana bazy danych, konieczna ze względu na system harmonogramowania. Ponieważ konkretna strona lub atrybut mogą teraz występować więcej niż jeden raz, prosty wiersz oznaczony jako “identyfikator jednostki” nie może spełniać roli podstawowego klucza. W wielu miejscach dodawany jest więc również “identyfikator wiersza”, co prowadzi do konieczności stworzenia nowych tabel sekwencyjnych, które pozwolą na obsługę wyzwalaczy awaryjnych dla wszystkich tabel przy użyciu nowych identyfikatorów jednostki/wiersza.

Drugą jest archiwum zamówień, dzięki któremu można uporządkować tabelę zamówień, aby zespołowi obsługi klienta łatwiej było czytać i skanować dane konkretnego zamówienia. Ponadto, odpowiedź na każde zapytanie skierowane do bazy danych będzie szybsza ze względu na mniejszą liczbę wpisów do przeszukania. Na pierwszy rzut oka zmiana ta może się wydawać niewielka, ale biorąc pod uwagę fakt, że już po dziesięciu tygodniach mielibyśmy do zeskanowania 15 tysięcy zamówień, umożliwia ona skrócenie o kilka milisekund każdego wyszukiwania.

Poza powyższymi zmianami mamy również do dyspozycji wariant Adobe Commerce w Chmurze. Jest to w zasadzie tylko Adobe Commerce we wstępnie zdefiniowanym rozwiązaniu chmurowym, które Adobe sprzedaje swoim klientom. To, czy będzie ono skuteczne i opłacalne, to już zupełnie inna kwestia.

Zacznijmy od początku.

Konfiguracja

Podstawowe elementy konfiguracji Magento nie mają żadnego wpływu na wydajność oprogramowania. Jeśli jednak dotrzesz do zaawansowanych opcji, drobne zmiany w jednej lub dwóch z nich mogą faktycznie spowolnić działanie witryny nawet dwukrotnie.

Konfiguracją, przy której należy zachować największą ostrożność, jest konfiguracja katalogu, a więc np. to, ile produktów jest wyświetlanych na stronie z listą produktów (w skrócie PLP). W tym przypadku hasło „mniej znaczy lepiej” sprawdzi się najlepiej. Ważne jest również, aby upewnić się, że klienci nie mają zbyt wielu opcji zmiany liczby widocznych produktów (o tym, czy nieskończone przewijanie i ładowanie ajax to dobra strategia, opowiemy innym razem). Optymalna liczba produktów z punktu widzenia deweloperów to 3 wiersze pomnożone przez liczbę produktów, które chcesz zobaczyć w wierszu na pulpicie – zwykle jest to 6, 9 lub 12.

Jest też kilka konfiguracji – jak legendarny już płaski katalog dla osób pracujących z Magento 1 – które nie są już traktowane jako zmiany wydajności. Warto o tym pamiętać, ponieważ niektórzy starsi programiści mogą chcieć zmienić je na opcję, która dziś nie jest już preferowana.

Podczas konfiguracji dobrze jest sprawdzić i poprawnie ustawić indeksowanie. Obecnie zaleca się, aby większość indeksów była aktualizowana zgodnie z harmonogramem (z wyjątkiem jednego) i nie mogę wymyślić żadnej przyczyny (zapasy, ceny), która mogłaby to w przyszłości zmienić, ponieważ miałoby to naprawdę duży wpływ na osiągane wyniki.

Szczególnie dobrą rzeczą jest również poznanie rozmiaru katalogu i uzyskanie liczby efektywnych SKU – to jest to, co nazywamy całkowitą liczbą wierszy i wersji produktu. Jest to łatwe do obliczenia, ponieważ jest to liczba SKU x liczba witryn x liczba grup klientów.

Jeśli masz na przykład tylko 10 000 produktów, ale 5 stron internetowych i 3 różne grupy klientów, to w rzeczywistości jest to 150000 efektywnych SKU — czyli naprawdę bardzo dużo. Dzięki zdaniu sobie z tego sprawy można dokonać drobnych zmian konfiguracji katalogu, aby go zmniejszyć – czy potrzebna jest piąta strona internetowa? Czy możemy usunąć jedną grupę klientów?

Obsługa zamówień

Jednym z elementów, które pozwalają każdemu sklepowi internetowemu obsłużyć więcej zamówień, jest właściwa obsługa zamówień. To oczywiste? Owszem, ale często jest to pomijane.

Pierwszą opcją, na którą należy zwrócić uwagę, jest zbieranie zamówień. Adobe Commerce pozwala nam na asynchroniczne zbieranie zamówień. Zamówienia są wówczas umieszczane w magazynie tymczasowym i masowo przenoszone do sieci Zarządzania Zamówieniami bez kolizji (jest to opcja konfiguracji, którą można zmienić w dowolnym momencie). Spowalnia to przetwarzanie zamówień w backendzie, ale pozwala frontendowi na przyjmowanie większej liczby zamówień w tym samym momencie.

Druga opcja to przetwarzanie zamówień – zawsze zalecane jest robienie tego zewnętrznie (ERP) i tylko aktualizowanie statusu w Magento za pomocą API. Istotna jest też częstotliwość takich aktualizacji – jeśli dzieje się to w większych ilościach, na przykład tylko raz dziennie przy ponad 5 tysiącach wierszy, to warto wykorzystać przy tym system kolejkowy.

Rozszerzenia zewnętrznych dostawców

Magento słynie ze znacznej liczby dostępnych rozszerzeń – zarówno darmowych, jak i płatnych. Jedną z zalet budowania sklepu internetowego na Magento mogłaby więc być możliwość korzystania z rozwiązań innych firm, aby szybko zapewnić dobre MVP. Niestety, w rzeczywistości jest to jednak bardzo trudne – istnieje znaczne ryzyko wystąpienia problemów z wydajnością podczas korzystania z rozszerzeń zewnętrznych dostawców.

Po pierwsze, nigdy nie możemy być pewni, jak dobry jest ich kod. Oczywiście, wewnętrzny zespół programistów może przeprowadzić audyt i stwierdzić, czy to rozszerzenie jest w porządku, czy nie. Jest to jednak dodatkowy koszt, a niektóre błędy mogą nie być łatwe do znalezienia.

Po drugie, nawet jeśli rozszerzenia są dobrze zaprojektowane i zakodowane, a dwa lub trzy z nich pracują w tym samym miejscu, obsługa tych samych danych może powodować niepotrzebne awarie. Na przykład, jeśli istnieją dwa rozszerzenia obsługujące wyświetlaną listę produktów, jedno pozwala nam na stworzenie niestandardowego porządku sortowania, a drugie po prostu dodaje porządek sortowania na podstawie sprzedaży – oba mogą dodać 3 lub 4 zapytania do bazy danych i spowolnić czas do pierwszego bajtu (TTFB) o 100 ms.

Zasadą jest więc unikanie rozszerzeń stron trzecich, jeśli tylko jest to możliwe, i trzymanie się podstawowych funkcji dostępnych w Magento.

Spersonalizowana logika biznesowa

Tu zasada działania jest prosta – za każdym razem, gdy dodajesz spersonalizowaną logikę biznesową do Adobe Commerce, domyślnie spowalniasz działanie oprogramowania. Jeśli Twoim głównym celem jest wydajność, kluczowe jest, by za każdym razem, gdy planujesz wprowadzenie nowej personalizacji, zapytać zespół ecommerce stojący za sklepem, czy jest to naprawdę konieczne. Być może jest jakiś sposób, aby tego uniknąć i zamiast tego użyć podstawowych funkcji Magento.

Jeżeli jednak nie ma możliwości, by tego uniknąć, należy zwrócić uwagę na kilka ważnych kwestii:

• po pierwsze, upewnij się, czy struktura bazy danych jest dobrze zaprojektowana i czy tabele mają poprawne klucze podstawowe, unikalne klucze i ogólnie klucze dla każdego typu zapytania, które może być wywoływane;
• po drugie, sprawdź, czy wykorzystujesz jedynie niezbędne preferencje i wtyczki. Każda kolejna preferencja i wtyczka stwarza ryzyko utraty cennych milisekund od TTFB, a w przypadku żądania typu ajax może stanowić duży problem;
• przeprowadź jak najmniej transformacji danych;
• zawsze miej na uwadze skalowalność – upewnij się, że architektura i kod mogą działać na wielu poziomach i nie będą współbieżne dla tych samych zasobów bazy danych.

Działania poprawiające wydajność w kodzie

Optymalizacja kodu pod kątem wydajności zawsze będzie jednym z najskuteczniejszych, lecz jednocześnie najtrudniejszych i najbardziej kosztownych sposobów na przyspieszenie działania sklepu internetowego. Programistom zadanie to zwykle zajmuje dużo czasu i nie zawsze jest łatwe do wykonania, gdyż może wiązać się z koniecznością przeprowadzenia wielu refaktoryzacji. Jeśli cały nowy personalizowany kod jest wykonywany poprawnie od samego początku i przechodzi testy jednostkowe, testy funkcjonalne i testy integracyjne, to istnieje duża szansa, że ​​niewielu programistów będzie w stanie skrócić każdą odrobinę milisekundy od uruchomienia kodu. W przeciwnym razie proces ten byłby ciągłą walką.

Oto kilka skutecznych sposobów radzenia sobie z optymalizacją kodu:

• unikaj zapętleń – dowiedz się, czy istnieje sposób na uzyskanie dokładniejszych danych, dzięki któremu nie będzie trzeba przechodzić przez cały zbiór produktów lub zamówień;
• odraczaj zapytania zewnętrzne, takie jak curls – wykorzystaj RabbitMQ lub zaplanuj je i użyj danych z pamięci podręcznej;
• unikaj wielu transformacji danych – staraj się operować na wartościach jak najbardziej zbliżonych do oryginału;
• staraj się nie używać wielu instrukcji „if-else” i nie zagnieżdżać ich.
• sprawdź, czy Magento ma już funkcję, której potrzebujesz – niektóre działania z backendu są już zdefiniowane (np. serializacja, naliczanie podatków itp.).

Działania poprawiające wydajność na serwerze

Jest to ogólne stwierdzenie, ponieważ w celu optymalnego wykorzystania zasobów sugerujemy użycie rozwiązania chmurowego, np. Azure, AWS czy dowolnego spośród dostępnych dziś na rynku. Głównym punktem naszego zainteresowania powinna tu być automatyczna skalowalność i wydzielenie różnych instancji dla różnych zastosowań, jeśli jest to możliwe.

Dobrym przykładem jest np. posiadanie oddzielnych serwerów dla frontendu i oddzielnych dla backendu. Można, oczywiście, pójść znacznie dalej i mieć dodatkowe instancje dedykowane tylko zapleczu administracyjnemu (panelowi administracyjnemu) lub przeznaczone tylko do przekierowywania check outu. W ten sposób spadek CPU i RAM w całej witrynie można łatwo złagodzić, gdyż będzie miał on wpływ tylko na jedną jej część. Co prawda nadal może wystąpić tu problem z bazą danych, ale można go rozwiązać przy typowej konfiguracji urządzeń pierwotnego i wtórnego.

Problem pojawia się w sytuacji, gdy mówimy o wielu zamówieniach dodawanych i zmienianych w tabeli zamówień. W takim przypadku poza dodaniem większej mocy dla podstawowej instancji bazy danych, możemy ją tylko lepiej skonfigurować na poziomie MySQL/MariaDB/Aurora.

Lista dobrych praktyk w tym zakresie obejmuje m.in.:

• Zmień wszystkie tabele w bazie danych na InnoDB, ponieważ niektórzy zewnętrzni dostawcy mogą nadal używać MyISAM.
• Zawsze dobrze jest sprawdzić, czy max_connection jest poprawnie skonfigurowane.
• Jeśli masz więcej niż 8 GB pamięci RAM w instancji bazy danych, ustaw innodb_buffer_pool_size na ok. 1 GB.
• Zweryfikuj wartość domyślną dla innodb_io_capacity i env w chmurze. Przy dyskach SSD warto zwiększyć tę wartość.

Ostatnią rzeczą, na którą należy zwrócić uwagę, jest konfiguracja PHP-fpm. Ta część może być trudna, ponieważ np. w środowisku chmury często nie ma prostego sposobu na jej szybkie skonfigurowanie.

Domyślny przykładowy plik, który znajduje się w repozytorium GIT Magento, jest całkiem dobry na początek, ale dość szybko będzie trzeba go zaktualizować, zaczynając od zmiany wartości „pm” na wartość “na żądanie”, oraz zmiany wartości pm.max_children tak, aby uwzględnić więcej pamięci RAM (pamięć RAM podzielona przez maksymalną wartość rozmiaru puli podrzędnej, zwykle około 100 MB).

Pamięć podręczna i CDN

Ostatnią częścią konfiguracji wydajności i pierwszą częścią, którą widzą klienci, jest pamięć podręczna. Istnieje kilka warstw pamięci podręcznej, których można używać z Magento, począwszy od Redis jako pamięci podręcznej dla bloków, przez całą pamięć podręczną strony, taką jak np. Varnish, a skończywszy na CDN, który dostarczy z najbliższego możliwego serwera niektóre pliki, takie jak skrypty JS czy obrazy.

Im więcej danych zbuforujesz, tym więcej (teoretycznie) zyskasz – ale jest też ciemna strona buforowania. Informacje, które wysyłamy do klientów, mogą być nieaktualne. Tak więc, jak zawsze, czeka nas długa podróż, której celem będzie znalezienie złotego środka pomiędzy tym, co powinno, a tym, co nie może być buforowane.

Jednak w przypadku CDN, zwykle warto skłaniać się ku buforowaniu większej ilości danych. Jeśli to możliwe, lepiej odłożyć ładowanie (i optymalizację) obrazów na zewnętrzne źródła. CDN takie jak Fastly lub Cloudflare mogą dostarczać i wysyłać lepiej zoptymalizowane obrazy internetowe bezpośrednio do klientów.

Podsumowanie

Zbierzmy na koniec w jednym miejscu wszystkie nasze wnioski i ustalenia:

• Optymalizacja wydajności zaczyna się jeszcze przed faktycznym rozwojem sklepu internetowego.
• Już w fazie odkrywania należy znaleźć odpowiedzi na pytania: Czy wpłynie to na wydajność? Jeśli tak, czy jest to niezbędne?
• Używaj tylko sprawdzonych i znanych rozszerzeń innych firm.
• Jeśli to możliwe, używaj jak najmniejszej liczby rozszerzeń innych firm.
• Nie oszczędzaj na konfiguracji serwera/chmury – lepiej wydać więcej na konfigurację początkową niż później wydawać jeszcze więcej na każdą kolejną rekonfigurację.
• Zainwestuj w mechanizm cachingu i CDN – dzięki temu strona szybko się rozrośnie.
• Pytania, które warto skierować do zespołu programistów:
• Czy indeksowanie i buforowanie jest włączone?
• Jak często import / eksport będzie przetwarzany i jak wpłynie to na frontend?
• Czy są obecne testy jednostkowe / testy funkcjonalne?
• Pytania, które warto skierować do zespołu biznesowego:
• Gdzie i jak często będą realizowane zamówienia?
• (Jeśli pojawi się prośba o nową funkcję) Kto z niej skorzysta? Jak często? Czy warto – nie tylko z biznesowego punktu widzenia, ale także biorąc pod uwagę to, jak wpłynie to na ogólną szybkość ładowania strony?