Medusa vs Magento: Porównanie Wydajności

Medusa jest 6,5 raza szybsza niż Magento! Dowiedz się, jak przeprowadziliśmy testy, czytając nasz artykuł.

Magento to doświadczony gracz na rynku eCommerce, znany ze swojego rozbudowanego, ale skomplikowanego systemu. Ostatnio skierował swoje kroki w stronę architektury headless, próbując nadążyć za rynkiem. Czy jednak ta zmiana sprawia, że może dorównać nowszym platformom API-First, takim jak Medusa, które zostały zaprojektowane od podstaw, by być headless?

To porównanie ma na celu sprawdzenie, czy Magento, może równać się z wydajnością platform zbudowanych z myślą o API od samego początku.

Co to jest Medusa?

Medusa to open-source platforma headless eCommerce, stworzona przy użyciu języka JavaScriptu. Zaprojektowana z myślą o możliwości dostosowania do każdego modelu biznesowego eCommerce, w tym skomplikowanych konfiguracji, jak platformy multi-vendor marketplace. Jej podejście oparte na API i modułowa architektura ułatwiają szybki rozwój i skalowalność.

Co to jest Magento (Adobe Commerce)?

Magento, obecnie jako Adobe Commerce, to wiodąca platforma eCommerce, ceniona za swój bogaty zestaw funkcji. Obsługuje architekturę headless, co pozwala firmom tworzyć spersonalizowane doświadczenia na froncie, jednocześnie korzystając z potężnych możliwości eCommerce Magento w backendzie.

Co porównujemy

W naszym porównaniu Medusy i Magento skupiamy się na wydajności API, analizując, jak efektywnie każda z platform obsługuje zapytania. Wydajność API jest kluczowa, ponieważ bezpośrednio wpływa na szybkość strony e-commerce, co wpływa na wiele aspektów sklepu internetowego - od doświadczeń użytkowników po pozycjonowanie w wyszukiwarkach.

Podczas testowania wydajności API zmierzymy średni czas ładowania oraz czas ładowania w 95. percentylu, bazując na http_req_duration.

http_req_duration

Aby porównać wydajność API oraz ogólną wydajność serwerów Medusy i Magento, skupiamy się na metryce http_req_duration. Ta metryka reprezentuje całkowity czas potrzebny na zakończenie żądania HTTP - od momentu jego wysłania po otrzymanie ostatniego bajta odpowiedzi. Obejmuje wszystkie całe zapytanie, co czyni ją dobrym wskaźnikiem oceny wydajności platformy eCommerce.

Znaczenie średniego czasu ładowania i 95. percentyla

• Średni czas ładowania: Ta metryka daje nam ogólny obraz tego, ile czasu zwykle potrzeba na wywołanie API we wszystkich testach. Jest pomocna w ustaleniu ogólnej wydajności, ale czasami może ukrywać problemy, takie jak sporadyczne opóźnienia czy wartości odstające.
• 95. percentyl: Zamiast skupiać się wyłącznie na średnich, koncentrujemy się na 95. percentylu, aby lepiej zrozumieć wydajność pod obciążeniem. Ta metryka pozwala nam zobaczyć, jak platforma sprawdza się w stresowych sytuacjach, wyłączając najbardziej ekstremalne przypadki. Jest to kluczowe dla e-commerce, ponieważ odzwierciedla doświadczenia niemal wszystkich użytkowników.

Dlaczego szybkość ładowania jest ważna?

Szybkość ładowania ma kluczowe znaczenie, ponieważ nawet niewielkie opóźnienia mogą drastycznie obniżyć współczynniki konwersji i sprzedaż. Szybko ładowane strony spełniają oczekiwania użytkowników, poprawiają pozycjonowanie w wyszukiwarkach i zwiększają szansę na utrzymanie zaangażowania użytkowników. Krótko mówiąc, szybsza strona bezpośrednio przekłada się na lepsze doświadczenia użytkownika i wzrost przychodów.

Aby dowiedzieć się więcej, przeczytaj nasz artykuł - "Jak zwiększyć sprzedaż w sklepie internetowym?"

Test: Dlaczego skupiamy się na pobieraniu danych produktów?

Skoncentrowaliśmy się na pobieraniu danych produktów jako głównym przypadku testowym dla naszego porównania. Decyzja ta opiera się na założeniu, że przeglądanie informacji o produkcie często stanowi pierwszy krok w podróży klienta do zakupu. Efektywne ładowanie szczegółów produktu utrzymuje zaangażowanie potencjalnych kupujących i redukuje wskaźnik odrzuceń.

Jak przeprowadzamy test

Oto jak przeprowadzamy nasz test wydajności:

Narzędzie k6 do testowania obciążenia

Do naszych testów używamy k6, narzędzia open-source do testowania wydajności. k6 zostało stworzone do symulowania ruchu w rzeczywistych warunkach na aplikacjach internetowych, dostarczając informacji o tym, jak systemy zachowują się w różnych warunkach. k6 pozwoli nam zasymulować ruch i zbadać wydajność API.

Aby upewnić się, że nasze wyniki testów koncentrują się wyłącznie na czasach odpowiedzi serwera i nie są pod wpływem zmian w opóźnieniach sieciowych, skonfigurowaliśmy nasze środowisko testowe k6 bezpośrednio na serwerze.

Środowisko testowe: Taki sam serwer

Uruchamiamy Medusę i Magento na identycznych serwerach, aby wyeliminować sprzęt jako zmienną. Każda z platform jest hostowana na instancji DigitalOcean Droplet, z 4 GiB RAM i 2 wirtualnymi CPU. Ta specyfikacja zapewnia, że obie platformy mają równy dostęp do zasobów, co czyni nasze porównanie wydajności jak najbardziej sprawiedliwym.

Brak systemów cache

Aby ocenić prawdziwą wydajność każdej z platform, przeprowadzamy nasze testy bez użycia jakichkolwiek systemów cache. To podejście pozwala nam zmierzyć prawdziwą wydajność backendu Medusy i Magento bez wpływu mechanizmów cachowania, które mogłyby zniekształcić wyniki.

Baza danych produktów

Obie platformy zostały wypełnione 1000 identycznymi produktami. Zapewnia to, że nasze testy porównują systemy na równych warunkach, z obiema platformami obsługującymi równą ilość danych podczas scenariuszy testowych.

Wdrożenie

Medusa Używamy wersję Medusy 1.20.2 z Node 18.20.0 na naszym serwerze, korzystając z Dockera.

Magento Używamy Magento Open Source 2.4.6-p4, działające na PHP 8.1 i Apache.

Rodzaje testów

Aby ocenić wydajność Medusy i Magento, przygotowaliśmy serię testów, które symulują różne scenariusze obciążenia platformy. Każdy scenariusz jest stosowany do obu platform i obejmuje dwa różne typy żądań:

• Pobranie pojedynczego produktu
• Pobranie 15 produktów z przesunięciem o 500.

Takie podejście pozwala nam ocenić, jak każda z platform radzi sobie z różnym stopniem zapotrzebowania i konkretnymi zadaniami związanymi z pobieraniem danych.

Scenariusze testowe

1. 50 iteracji z 1 użytkownikiem: Ten test symuluje sytuację, w której użytkownik dokonuje 50 kolejnych żądań. Jest zaprojektowany, aby ocenić, jak platformy radzą sobie z lekkim, ale stałym obciążeniem, dając wgląd w ich efektywność w obsłudze działań pojedynczego użytkownika.
2. 10 użytkowników jednocześnie (przez 30 sekund): Symulując 10 użytkowników działających na platformie jednocześnie, ten test ocenia zdolność platform do obsługi wielu żądań równocześnie. Jest to podstawowy test, odzwierciedlający realistyczny scenariusz dla małych do średnich sklepów e-commerce w okresach niskiego do umiarkowanego ruchu.
3. 25 użytkowników jednocześnie (przez 30s): Ten scenariusz znacząco zwiększa ilość jednoczesnych zapytań, testując wydajność platform pod średnim obciążeniem. Symuluje bardziej intensywny okres zakupów, taki jak wyprzedaż, podczas którego wielu użytkowników przegląda i wchodzi w interakcję ze stroną jednocześnie.
4. 50 użytkowników jednocześnie (przez 30s): Najbardziej wymagający test, symulujący wydarzenie o wysokim ruchu, sprawdzający skalowalność platform i zarządzanie zasobami pod ciężkim obciążeniem. Jest to wskaźnik szczytowych czasów zakupów, takich jak znaczące wyprzedaże lub gorączka zakupowa w okresie świątecznym.

Testowane żądania

• Pobranie pojedynczego produktu: Mierzy czas odpowiedzi platform, gdy użytkownik prosi o informacje dotyczące pojedynczego produktu.
• Pobranie 15 produktów z offset 500: Ocena wydajności platform w pobieraniu danych produktów z paginacją, co jest typowym scenariuszem dla użytkowników przeglądających sklepy z obszerną kolekcją produktów.

Test: Pobieranie pojedynczego produktu

Magento endpoint

/rest/V1/products/[product_sku]

Medusa endpoint

/store/products/[prod_id]

50 iteracji z 1 użytkownikiem

a. Magento

b. Medusa

c. Magento vs Medusa

10 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

25 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

50 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

Test: pobieranie 15 produktów z offset 500

Magento endpoint

/rest/V1/products?searchCriteria[pageSize]=15&searchCriteria[currentPage]=34

Medusa endpoint

/store/products?limit=15&offset=500

50 iteracji z 1 użytkownikiem

a. Magento

b. Medusa

c. Magento vs Medusa

10 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

25 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

50 użytkowników jednocześnie przez 30s

a. Magento

b. Medusa

c. Magento vs Medusa

Podsumowanie

Nasze porównanie wydajności między API Magento a Medusa pokazuje znaczną przewagę Medusy. Mimo że odpowiedzi z API Medusy są cięższe pod względem rozmiaru danych, czasy odpowiedzi Medusy są niezaprzeczalnie znacznie szybsze w każdym przypadku.

W testach symulujących wielu użytkowników wysyłających zapytania do systemu jednocześnie zaobserwowaliśmy znaczącą różnicę w czasach odpowiedzi i objętości przetwarzanych danych. API Medusy pozwoliło nam na wykonanie większej liczby żądań w tym samym przedziale czasowym, pobierając więcej danych.

Czasy 95. percentyla (p(95)) ze wszystkich testów ujawniają znaczące różnice w wydajności:

• Przy pobieraniu pojedynczego produktu w 50 iteracjach z jednym użytkownikiem, Medusa była 4,33 raza szybsza niż Magento.
• Gdy obciążenie wzrosło do 10, 25 i 50 użytkowników jednocześnie przez 30 sekund, Medusa konsekwentnie przewyższała Magento, będąc odpowiednio 6,03, 11,01 i 7,34 razy szybsza.
• Przewaga wydajności rozciągała się również na pobieranie 15 produktów jednocześnie, z Medusą będącą od 5,98 do 7,01 razy szybszą przy różnych obciążeniach użytkownikami.

Medusa przewyższa Magento, będąc 6,5 raza szybsza przy tym samym ustawieniu serwera. Oznacza to, że Medusa może efektywnie obsłużyć znacznie więcej żądań i użytkowników przy tych samych zasobach serwera.

Na dzisiejszym rynku każda milisekunda liczy się w kierunku dokonania sprzedaży. Wybór szybkiego backendu eCommerce, takiego jak Medusa, może być kluczem do utrzymania przewagi.