Przyspiesz mydło Magento v1

10

Mam wiele pytań do doświadczonych programistów Magento:

  1. Czy można poprawić prędkość mydlanego interfejsu API Magento v1? Gdy żądasz danych, magento szybko kompiluje proste informacje, takie jak adres klienta itp., Kosztuje 1,5 sekundy.

    Żądanie wielu możliwych istotnych węzłów danych może szybko kosztować około 5-7 sekund.

    Teraz już robię te żądania za pośrednictwem żądań AJAX, więc interfejs strony ładuje się szybko, ale poprawa prędkości byłaby miła.

  2. Czy może lepiej byłoby napisać własną aplikację, aby przekazać mi odpowiednie informacje bezpośrednio z bazy danych magento? Db nie jest tak skomplikowany, a jeśli wykonam bezpośrednie zapytanie, ładuje się w ciągu 100 sekund z wynikami ...

    Jedyne rozważanie, jakie mam przy tej opcji, to:

    1. Co się stanie, jeśli Magento zaktualizuje i zmieni schemat bazy danych?
    2. Czy konfiguracja bazy danych Magento jest stosunkowo bezpieczna / kompatybilna w dół?

Czy ktoś ma jakieś doświadczenie z tym i swoimi sukcesami lub historiami? Muszę dokonać świadomej decyzji, aby wiedzieć, jak postępować.

performance api Tschallacka
źródło
1
Prawdopodobnie jest związany z PHP, nie MySQL, Nginx ani nic innego . Tak samo jak reszta twojego sklepu. Przyspiesz swój sklep, a interfejs API będzie dostępny. Jednak nigdy nie będzie to błyskawiczne - metody przepływu danych / API są wolne, niezależnie od tego, więc niestandardowe implementacje zawsze osiągają lepsze wyniki kosztem zarządzania / czasu wdrożenia / aktualizacji.
Ben Lessani - Sonassi
3
nie, to nie jest związane z php ... to cała konfiguracja Magento, która niesamowicie spowalnia. Wykonanie żądania interfejsu API mydła trwa dłużej niż zamówienie dużej strony z wieloma sklepami i koszykiem. Coś jest zniekształcone w projekcie Magento.
Tschallacka

Odpowiedzi:

8

Dokładnie napotkałem dokładnie ten problem i obejrzałem go, pracując bezpośrednio z obiektami Magento. Myślę, że istnieją obawy dotyczące zmian kodu i czegokolwiek, co opisujesz, ale większość mojego kodu znajduje się w skryptach jednorazowego użytku do ładowania starych danych, takie rzeczy, więc było to drobne zaniepokojenie. Bezpośrednia praca z obiektami Magento miała również tę dodatkową zaletę, że uczyłem się wewnętrznych elementów nieco więcej niż bym tylko dzięki API SOAP - z pewnością bardziej stroma krzywa uczenia się, ale mam większą wiedzę na temat tego, co się dzieje tam, niż gdybym nigdy nie używał interfejsu API SOAP.

Inną opcją, którą wypróbowaliśmy, było buforowanie danych przy użyciu Memcached (lub coś takiego, jak Redis też by działało), chociaż teraz musisz się martwić, jak często aktualizować pamięć podręczną, skąd i tym podobne. Ale osiąga cel znacznie, dużo szybciej. Myślę, że to, czy jest to dobra opcja, zależy od tego, co próbujesz zrobić.

Mikrofon
źródło
Cóż, gdybym zrobił coś z samego Magento, nie zyskałbym większej prędkości, ponieważ Magento wciąż musi zostać „uruchomione”, aby obsłużyć żądanie. Lubię API mydła, ponieważ „nie zmienia się”, ale nienawidzę faktu, że tak niewiarygodne jest wolne reagowanie na najprostsze pytania. nawet główna strona, która musi obsłużyć znacznie więcej żądań, jest znacznie szybsza.
Tschallacka
Staram się połączyć magento z naszym oprogramowaniem ERP, więc potrzebuję dostępu do najnowszych danych w dowolnym momencie.
Tschallacka
1
Być może - w moim przypadku pisałem rzeczy, które ładowałyby zamówienie według identyfikatora przyrostu, a następnie wykonywały akcję na podstawie jego danych. Ładowanie pełnego zamówienia trwało około 1,5 sekundy w interfejsie API SOAP lub ułamek sekundy w formie „surowego obiektu”. Wybór był dla mnie oczywisty, kiedy załadowałem setki z nich za jednym razem. Kolejnym ograniczeniem jest to, że wykonując styl „aplikacji Magento”, musi on znajdować się na tym samym serwerze. W moim przypadku wcale mi to nie przeszkadzało, ale warto o tym pamiętać.
Mike
1
Jak załadowałeś wszystko w postaci surowego obiektu?
Tschallacka
$order = Mage::getModel('sales/order')->load($order_id);, w zasadzie. W tym wątku na forum jest fragment lub dwa, które mogą ilustrować więcej: magentocommerce.com/boards/viewthread/18629
Mike
6

Przyspieszenie interfejsu SOAP będzie trudne. Zawsze możesz wrzucić jakiś dodatkowy sprzęt (szybszy serwer MySQL) lub uruchomić sklep na NginX, co po kilku milisekundach NginX lepiej obsługuje duże ilości żądań HTTP. Buforowanie nie pomogłoby tak bardzo, ponieważ odpowiedź większości połączeń będzie się różnić za każdym razem.

Zbudowanie własnego interfejsu API od podstaw przy użyciu modeli Magento Core może być najszybszym rozwiązaniem, ponieważ możesz dostosować kod w celu zwiększenia wydajności, ładując tylko dokładnie to, czego potrzebujesz. Z mojego doświadczenia w korzystaniu z podstawowych klas niewiele się zmieniło między, powiedzmy, wersją 1.5 a 1.7

Edycja: Zapomniałem, mała szybka wygrana może wynikać z włączenia kompresji danych wyjściowych gzip w pliku htaccess lub php.ini lub jeśli masz ochotę przenieść interfejs SOAP na inny serwer przy użyciu tej samej bazy danych, jeśli baza danych MySQL nie jest wąskie gardło

Sander Mangel
źródło
1
baza danych mysql nie jest szyjką butelki, szyjka butelki magento uruchamia wszystkie pliki konfiguracyjne, ładuje każdy kawałek badziewia, kompiluje API mydła, a potem w końcu pamięta, że ​​wysłałem żądanie, pobierz te dane, oceń je, skompiluj w żądanym formacie, sprawdź poprawność formatu, a następnie wyślij go przez połączenie mydła .... Sprawdź czek, sprawdź Podwójne sprawdzenie jest miłe ... ale jest zbyt wolne. Na początku będzie dobrze, ale w pewnym momencie będzie musiał przyspieszyć.
Tschallacka
Natywna pamięć podręczna Magento powinna ci w tym pomóc z łączeniem plików konfiguracyjnych, a kompilator może przyspieszyć kod. Również akcelerator PHP ( en.wikipedia.org/wiki/PHP_accelerator ) zwiększyłby twoją wydajność tutaj. Ale w twoim przypadku warto zastanowić się nad budowaniem własnego interfejsu API, który korzysta z interfejsu API rdzenia Magento.
Sander Mangel