Rosnący katalog może poważnie obciążyć synchronizację API. Duże zadania mogą spowolnić działanie, przekroczyć limit czasu lub zostać przerwane przedwcześnie. Aby zarządzać limitami obciążenia API PrestaShop , podziel zadanie na mniejsze strony. Pobieraj tylko potrzebne pola. Ogranicz liczbę wywołań jednocześnie. Zapisz również postęp, aby nieudane zadanie mogło zostać ponownie uruchomione od właściwego miejsca.
Nie ma jednej, bezpiecznej stawki żądań, która sprawdzi się w każdym sklepie. Bezpieczna stawka zależy od serwera, bazy danych, modułów, planu hostingowego i konfiguracji sieci. Przetestuj swój system, zamiast kopiować stałą wartość z innego projektu.
1.0 Czym są limity szybkości interfejsu API?
Limit szybkości określa liczbę wywołań API, które klient może wykonać w określonym czasie. Bramka może zliczać wywołania na sekundę, minutę lub godzinę. Jeśli klient wyśle zbyt wiele wywołań, usługa może opóźnić lub odrzucić nowe.
W praktyce limity szybkości interfejsu API PrestaShop mogą wynikać ze sklepu PrestaShop lub innej warstwy jego stosu hostingowego.
Rozmiar żądania to osobna kwestia. Jedno wywołanie może wymagać bardzo dużego zestawu danych. To wywołanie może zużywać dużo pamięci, czasu bazy danych i przepustowości.
Rozwiązanie zależy od problemu:
- Połączenia przychodzące zbyt szybko wymagają niższej szybkości i mniejszej ilości pracy równoległej.
- W przypadku odpowiedzi o dużych rozmiarach użyj stron, filtrów i mniejszej liczby pól.
- Jeśli wystąpią obydwa problemy, należy użyć obu zestawów elementów sterujących.
2.0 Limity szybkości interfejsu API PrestaShop: Czy istnieje stały limit?
PrestaShop nie publikuje jednego limitu szybkości usługi internetowej dla każdego sklepu. Nie traktuj losowej wartości żądań na sekundę jako oficjalnej reguły PrestaShop.
Limit może wynikać z innej części konfiguracji. Apache, Nginx, serwer proxy, zapora sieciowa lub host mogą blokować duży ruch. Regułę może również ustawić sieć CDN, brama, moduł niestandardowy lub aplikacja kliencka.
Sprawdź status HTTP, treść i nagłówki. Następnie przejrzyj logi z PrestaShop, serwera i dowolnej bramki. Logi synchronizacji powinny rejestrować czas, trasę, status i czas odpowiedzi.
Poszukaj wzorców. Być może błąd pojawia się tylko wtedy, gdy uruchomionych jest kilka procesów roboczych. Zamiast tego wyzwalaczem mogą być duże odpowiedzi. W innych przypadkach awarie pojawiają się po określonej liczbie wywołań. Przekroczenie limitu czasu lub błąd HTTP 500 nie dowodzą, że przyczyną awarii było ograniczenie przepustowości.
3.0 Dlaczego duże zapytania do API PrestaShop powodują problemy
Duża lista może zmusić bazę danych do wykonania kosztownego zapytania. PHP potrzebuje pamięci do zbudowania odpowiedzi. Serwer musi wtedy wysłać duży plik XML lub JSON.
Nieudane, duże żądanie jest trudne do odzyskania. Klient może potrzebować ponownie pobrać całą listę, co zwiększa obciążenie.
Kilka dużych zapytań może również konkurować z klientami. Przewodnik wydajności PrestaShop pokazuje, że szybkość zależy od całego systemu. Buforowanie, projekt bazy danych, ustawienia serwera i moduły – wszystkie te elementy mają znaczenie.
Nie dąż do największego żądania, jakie serwer może obsłużyć jednorazowo. Wybierz mniejszą jednostkę, która będzie działać poprawnie za każdym razem. Powinna być również łatwa do ponowienia.
4.0 Jak obsługiwać duże żądania API w sklepie PrestaShop
4.1 Podziel listy na strony
Paginacja ładuje długą listę w mniejszych częściach. Synchronizacja odczytuje jedną grupę, przetwarza ją, a następnie pobiera kolejną. Jeśli się nie powiedzie, uruchamia się ponownie od ostatniego zapisanego punktu.
Ta metoda sprawia, że limity wydajności interfejsu API PrestaShop są łatwiejsze do spełnienia, ponieważ każda jednostka pracy pozostaje niewielka.
Usługa internetowa PrestaShop 9 obsługuje wartość limitu w postaci [offset,]limit . Jej offset zaczyna się od zera. Zgodnie z oficjalnym przewodnikiem, opcja ta może być używana do paginacji.
Rysunek 2. Przykład paginacji i wyboru pól usługi internetowej PrestaShop 7.
Rysunek 3. Przykład paginacji i wyboru pól usługi internetowej PrestaShop 8.
Rysunek 4. Przykład paginacji i wyboru pól usługi internetowej PrestaShop 9.
Wybierz rozmiar strony poprzez testy. Hosting współdzielony może wymagać mniejszych stron niż serwer dedykowany. Złożone dane produktowe również mogą wymagać mniejszych stron.
Zachowaj stabilną kolejność sortowania, ponieważ rekordy mogą się zmieniać podczas długiej synchronizacji. Wiarygodna data zmiany lub zapisany identyfikator mogą zapewnić bezpieczniejsze aktualizacje. Sprawdź, które filtry i pola sortowania obsługuje Twoja wersja PrestaShop.
4.2 Poproś o mniej pól
Opcja wyświetlania usługi sieciowej może zwracać wybrane pola zamiast wszystkich pól. Należy jej używać, gdy zadanie wymaga tylko kilku wartości. Na przykład synchronizacja zapasów może nie wymagać pełnych opisów i innych szczegółów produktu.
Mniejsze odpowiedzi ładują się szybciej i zużywają mniej pamięci. Najpierw przetestuj złożone dane produktowe w sklepie testowym.
4.3 Synchronizuj tylko to, co zostało zmienione
Pełny import ma sens podczas konfiguracji lub okazjonalnego sprawdzania. Większość codziennych zadań powinna unikać ponownego odczytywania całego katalogu.
Jeśli zasób na to pozwala, pobieraj tylko nowe lub zmienione rekordy. Zapisz kolejny punkt kontrolny po zapisaniu bieżącej strony. Jeśli zadanie zostanie przerwane, można je wznowić bez pomijania danych.
Usuń duplikaty wywołań. Przechowuj stabilne dane, takie jak listy krajów, w pamięci podręcznej przez odpowiedni czas. Nadaj każdej pamięci podręcznej jasną regułę wygaśnięcia lub odświeżania.
5. Jak poradzić sobie z błędem HTTP 429
HTTP 429 oznacza, że usługa uważa, że klient wysłał zbyt wiele połączeń w określonym czasie. Ten status jest zdefiniowany w RFC 6585. Odpowiedź może zawierać komunikat Retry-After , który informuje klienta, kiedy ma spróbować ponownie.
Rysunek 1. Przykładowa odpowiedź HTTP 429 z nagłówkami Retry-After i rate-limit.
Sprawdzając limity szybkości API PrestaShop , traktuj błąd 429 jako wskazówkę. Nie dowodzi on, że reguła została ustalona przez rdzeń PrestaShop.
Gdy Twoja integracja otrzyma odpowiedź 429:
- Rejestruj trasę, czas, identyfikator zadania, status i przydatne nagłówki.
- Obserwuj Spróbuj ponownie po gdy wartość jest obecna i prawidłowa.
- Zamiast próbować od razu wykonać zadanie ponownie, wstrzymaj je.
- Jeśli błąd wystąpi ponownie, zmniejsz częstotliwość połączeń lub liczbę pracowników.
- Powiadom zespół, gdy zadanie wykorzysta wszystkie dozwolone ponowne próby.
Nie zakładaj, że odpowiedź 429 została wysłana przez rdzeń PrestaShop. Mogło ją wysłać proxy, brama sieciowa, zapora sieciowa, host lub zewnętrzne API. Znajdź to źródło przed zmianą klienta.
6. Jak działa logika ponawiania prób i wycofywania
Niektóre awarie są krótkotrwałe. Połączenie sieciowe może zostać zerwane lub zajęty serwer może zwrócić błąd. Ponowna próba może pomóc, ale natychmiastowa ponowna próba może zwiększyć obciążenie.
Backoff dodaje oczekiwanie przed kolejną próbą. Jeśli wywołanie ponownie się nie powiedzie, klient czeka dłużej. Niewielkie, losowe opóźnienie może uniemożliwić jednoczesne wybudzenie wielu procesów roboczych. Ta metoda jest ogólną praktyką API, a nie regułą wbudowaną w PrestaShop.
Każdy proces ponawiania prób wymaga limitu. Ustaw maksymalną liczbę prób i maksymalny czas oczekiwania. Ponawiaj tylko błędy, które mogą same się usunąć. Błędne dane logowania, brakujące uprawnienia i nieprawidłowe dane wymagają naprawy, a nie kolejnych wywołań.
Zachowaj szczególną ostrożność przy żądaniach zapisu. Pierwsze wywołanie mogło zmienić dane, nawet jeśli klient nie otrzymał odpowiedzi. Ponowna próba bez odpowiedzi może spowodować utworzenie duplikatu lub zastąpienie nowej wartości.
7. Najlepsze praktyki dotyczące limitów szybkości i wydajności interfejsu API PrestaShop
Podczas dostrajania limitów szybkości interfejsu API PrestaShop należy używać kilku małych elementów sterujących jednocześnie:
- Podziel duże listy na strony i zapisz punkt kontrolny.
- Pobierz tylko pola i rekordy potrzebne zadaniu.
- Ustaw limit dla pracowników równoległych.
- Stosuj rozsądne limity połączeń i odpowiedzi.
- Przechowuj w pamięci podręcznej wolno zmieniające się dane i definiuj moment ich wygaśnięcia.
- Zastosuj ograniczone wycofywanie się z działań w przypadku krótkoterminowych awarii.
- Rejestruj kody statusu, czasy reakcji, ponowne próby i rozmiary stron.
- Monitoruj czas realizacji zadania, wskaźnik błędów, wykorzystanie pamięci, obciążenie serwera i zaległości.
- Przeprowadzaj szczegółowe kontrole poza godzinami największego ruchu w sklepie.
- Przed uruchomieniem przeprowadź test przy użyciu realistycznej ilości danych.
Te kroki są zgodne z ogólnymi zaleceniami dotyczącymi paginacji dużych list, skupienia odpowiedzi na pytania i monitorowania korzystania z API . Należy jednak pamiętać, że każde ustawienie powinno być oparte na danych ze sklepu.
8. Przykład: Synchronizacja dużego katalogu produktów
Wyobraź sobie zadanie, które pobiera pełne dane każdego produktu. Uruchamia wiele procesów roboczych i nie zapisuje postępu. Jedno żądanie przekracza limit czasu, więc całe zadanie zaczyna się od nowa. Następnie pobiera te same niezmienione produkty, co dodatkowo obciąża sklep.
Lepsza wersja korzysta z przetestowanego rozmiaru strony i prosi tylko o niezbędne pola. Zapisuje każdą stronę i zapisuje punkt kontrolny. Następna strona uruchamia się, gdy pojemność jest dostępna.
Po wystąpieniu krótkotrwałego błędu, pracownik rejestruje go i czeka. W przypadku odpowiedzi 429, śledzi szczegóły prawidłowych ponownych prób. Późniejsze uruchomienia pobierają tylko zmienione rekordy, jeśli jest to obsługiwane. Zaplanowane pełne sprawdzenie może wykryć pominięte aktualizacje.
Ta konstrukcja może wysyłać mniej połączeń na sekundę. Jednak często kończy pracę bardziej niezawodnie, ponieważ praca jest stabilna i łatwa do wznowienia.
9. Zbuduj bardziej niezawodną integrację PrestaShop
Prawidłowe zarządzanie limitami przepustowości API PrestaShop zaczyna się od dowodów. Znajdź warstwę, która stosuje limit. Następnie zdecyduj, czy masz za dużo wywołań, za dużo danych, czy jedno i drugie.
Użyj paginacji i wybranych pól, aby zminimalizować rozmiar każdej odpowiedzi. Dodaj synchronizacje oparte na zmianach, staranne buforowanie i limity liczby pracowników, aby ograniczyć ruch. Na koniec użyj logów, monitorowania i ograniczonej liczby ponownych prób, aby awarie były jasne i bezpieczne do odzyskania.
Zanim skalujesz synchronizację, sprawdź opcje usługi sieciowej dla swojej wersji PrestaShop. Przetestuj całe zadanie z realistycznymi danymi. W większości przypadków małe zadanie, które można wznowić, jest bezpieczniejsze niż jedno duże żądanie.
Jeśli szukasz niezawodnych rozwiązań PrestaShop, aplikacji na iOS i Androida, niestandardowych zmian w witrynach i migracji, właściciele sklepów mogą się z nami skontaktować pod adresem [email protected] . Możesz również skontaktować się z naszym działem pomocy technicznej.
