Un catalogo in continua crescita può mettere a dura prova la sincronizzazione delle API. Le operazioni di grandi dimensioni possono rallentare, andare in timeout o interrompersi prematuramente. Per gestire i limiti di frequenza delle API di PrestaShop , è consigliabile suddividere il lavoro in pagine più piccole. Recuperare solo i campi necessari. Limitare il numero di chiamate simultanee. Inoltre, salvare i progressi in modo che un'operazione interrotta possa essere riavviata dal punto corretto.
Non esiste una frequenza di richieste che funzioni per ogni negozio. La frequenza sicura dipende dal server, dal database, dai moduli, dal piano di hosting e dalla configurazione di rete. Testa il tuo sistema invece di copiare un valore fisso da un altro progetto.
1.0 Cosa sono i limiti di frequenza delle API?
Un limite di frequenza definisce il numero di chiamate API che un client può effettuare in un determinato intervallo di tempo. Un gateway può contare le chiamate al secondo, al minuto o all'ora. Se il client invia troppe chiamate, il servizio potrebbe ritardarle o rifiutarle.
In pratica, i limiti di frequenza dell'API di PrestaShop possono provenire dal negozio PrestaShop stesso o da un altro livello della sua infrastruttura di hosting.
La dimensione della richiesta è una questione a parte. Una singola chiamata può richiedere un set di dati molto ampio. Tale chiamata può consumare molta memoria, tempo di accesso al database e larghezza di banda.
La soluzione dipende dal problema:
- Le chiamate in arrivo troppo rapide richiedono una tariffa inferiore e meno lavoro parallelo.
- Per risposte di grandi dimensioni, utilizzare pagine, filtri e un numero inferiore di campi.
- Quando si verificano entrambi i problemi, utilizzare entrambi i set di comandi.
Limiti di frequenza dell'API PrestaShop 2.0: esiste un limite fisso?
PrestaShop non pubblica un limite di richieste al secondo unico per ogni negozio. Non considerare un valore casuale di richieste al secondo come una regola ufficiale di PrestaShop.
Il limite potrebbe derivare da un altro componente della tua configurazione. Apache, Nginx, un proxy, un firewall o un host potrebbero bloccare un traffico elevato. Anche una CDN, un gateway, un modulo personalizzato o un'applicazione client potrebbero impostare una regola.
Verifica lo stato HTTP, il corpo e le intestazioni. Quindi esamina i log di PrestaShop, del server e di qualsiasi gateway. I log di sincronizzazione dovrebbero registrare l'ora, il percorso, lo stato e il tempo di risposta.
Cerca degli schemi ricorrenti. Forse l'errore si verifica solo quando sono in esecuzione diversi worker. In alternativa, la causa potrebbe essere un elevato numero di risposte. In altri casi, i malfunzionamenti iniziano dopo un certo numero di chiamate. Un timeout o un errore HTTP 500 non dimostrano che la limitazione della frequenza delle richieste abbia causato il problema.
3.0 Perché le richieste API di PrestaShop di grandi dimensioni causano problemi
Un elenco di grandi dimensioni può costringere il database a eseguire una query onerosa. PHP necessita di memoria per generare la risposta. Il server deve quindi inviare un file XML o JSON di grandi dimensioni.
Un'operazione di grandi dimensioni non andata a buon fine è difficile da recuperare. Il client potrebbe dover scaricare nuovamente l'intero elenco, il che comporta un carico maggiore.
Diverse richieste di grandi dimensioni possono entrare in competizione con gli acquirenti. La guida alle prestazioni di PrestaShop mostra che la velocità dipende dall'intero sistema. Cache, progettazione del database, impostazioni del server e moduli sono tutti elementi importanti.
Non puntare alla richiesta più grande che il tuo server può gestire in un'unica operazione. Scegli un'unità di misura più piccola che funzioni correttamente ogni volta. Dovrebbe anche essere facile riprovare.
4.0 Come gestire richieste API di grandi dimensioni in un negozio PrestaShop
4.1 Dividere gli elenchi in pagine
La paginazione carica un lungo elenco in parti più piccole. Una sincronizzazione legge un gruppo, lo elabora e poi recupera il successivo. In caso di errore, riprende dall'ultimo punto salvato.
Questo metodo semplifica la gestione dei limiti di frequenza delle API di PrestaShop, poiché ogni unità di lavoro rimane di piccole dimensioni.
PrestaShop 9 Webservice supporta un valore limite nella forma [offset,]limit . Il suo offset parte da zero. Secondo la guida ufficiale, questa opzione può essere utilizzata per la paginazione.
Figura 2. Esempio di paginazione e selezione dei campi tramite servizio web di PrestaShop 7.
Figura 3. Esempio di paginazione e selezione dei campi del servizio web PrestaShop 8.
Figura 4. Esempio di paginazione e selezione dei campi del servizio web PrestaShop 9.
Scegli la dimensione della pagina tramite test. L'hosting condiviso potrebbe richiedere pagine più piccole rispetto a un server dedicato. Anche i dati complessi del prodotto potrebbero necessitare di pagine più piccole.
Mantieni stabile l'ordine di visualizzazione, poiché i record possono cambiare durante una sincronizzazione prolungata. Una data di modifica attendibile o un ID salvato possono garantire aggiornamenti più sicuri. Verifica quali filtri e campi di ordinamento sono supportati dalla tua versione di PrestaShop.
4.2 Richiedi meno campi
L' opzione di visualizzazione del servizio Web consente di restituire solo i campi selezionati anziché tutti. Utilizzatela quando l'operazione richiede solo pochi valori. Una sincronizzazione di magazzino, ad esempio, potrebbe non necessitare di descrizioni complete e altri dettagli sui prodotti.
Le risposte più piccole si caricano più velocemente e utilizzano meno memoria. Testa prima i dati complessi del prodotto su un negozio di staging.
4.3 Sincronizza solo ciò che è cambiato
Un'importazione completa ha senso durante la configurazione o per un controllo occasionale. Per la maggior parte delle attività quotidiane, è meglio evitare di dover rileggere l'intero catalogo.
Laddove le risorse lo consentano, recupera solo i record nuovi o modificati. Salva il checkpoint successivo dopo aver salvato la pagina corrente. Se il processo si interrompe, può quindi riprendere senza saltare dati.
Rimuovi le chiamate duplicate. Memorizza nella cache i dati stabili, come gli elenchi dei paesi, per un periodo di tempo adeguato. Assegna a ogni cache una chiara regola di scadenza o di aggiornamento.
5. Come gestire un errore HTTP 429
Il codice HTTP 429 indica che il servizio ritiene che un client abbia inviato troppe chiamate in un determinato intervallo di tempo. Questo stato è definito nella RFC 6585. La risposta può includere l'opzione Retry-After , che indica al client quando riprovare.
Figura 1. Esempio di risposta HTTP 429 con intestazioni Retry-After e rate-limit.
Quando si analizzano i limiti di frequenza delle API di PrestaShop , un errore 429 va considerato come un indizio. Non dimostra che la regola sia stata impostata dal core di PrestaShop.
Quando la tua integrazione riceve una risposta 429:
- Registra il percorso, l'orario, l'ID del lavoro, lo stato e le intestazioni utili.
- Follow Riprova dopo quando il valore è presente e valido.
- Metti in pausa l'attività interessata invece di riprovare subito.
- Se l'errore si ripresenta, ridurre la frequenza delle chiamate o il numero di operatori.
- Avvisa il team quando l'operazione ha esaurito tutti i tentativi consentiti.
Non dare per scontato che la risposta 429 sia stata inviata dal core di PrestaShop. Potrebbe essere stata inviata da un proxy, un gateway, un firewall, un host o un'API di terze parti. Individua la fonte prima di modificare il client.
6. Come funzionano la logica di ripetizione e il backoff
Alcuni guasti sono di breve durata. Un collegamento di rete potrebbe interrompersi oppure un server sovraccarico potrebbe restituire un errore. Un nuovo tentativo può essere d'aiuto, ma un tentativo immediato potrebbe sovraccaricare ulteriormente il sistema.
Il backoff aggiunge un intervallo di tempo prima del tentativo successivo. Se la chiamata fallisce di nuovo, il client attende più a lungo. Un piccolo ritardo casuale può impedire che molti worker si riattivino contemporaneamente. Questo metodo è una pratica API generale, non una regola integrata in PrestaShop.
Ogni processo di ripetizione deve avere un limite. Imposta un numero massimo di tentativi e un tempo di attesa massimo. Ripeti solo gli errori che potrebbero risolversi da soli. Credenziali di accesso errate, permessi mancanti e dati non validi richiedono una correzione, non ulteriori chiamate.
Presta particolare attenzione alle richieste di scrittura. La prima chiamata potrebbe aver modificato i dati anche se il client non ha ricevuto la risposta. Un tentativo di ripetizione alla cieca potrebbe quindi creare un duplicato o sostituire un valore più recente.
7. Procedure consigliate per i limiti di frequenza e le prestazioni dell'API di PrestaShop
Quando si ottimizzano i limiti di frequenza dell'API di PrestaShop , è consigliabile utilizzare contemporaneamente diversi piccoli controlli:
- Suddividi gli elenchi lunghi in pagine e salva un punto di controllo.
- Recupera solo i campi e i record necessari per il lavoro.
- Imposta un limite al numero di processi paralleli.
- Utilizzare timeout di connessione e di risposta appropriati.
- Memorizza nella cache i dati che cambiano lentamente e definisci quando scadono.
- Applicare un margine di sicurezza limitato ai guasti a breve termine.
- Registra i codici di stato, i tempi di risposta, i tentativi e le dimensioni delle pagine.
- Monitora i tempi di esecuzione, il tasso di errore, l'utilizzo della memoria, il carico del server e il backlog.
- Effettua controlli completi e approfonditi al di fuori degli orari di maggiore affluenza del negozio.
- Prima di pubblicare il progetto, effettuate dei test con una quantità di dati realistica.
Questi passaggi sono in linea con consigli più generali per impaginare elenchi di grandi dimensioni, mantenere le risposte focalizzate e monitorare l'utilizzo delle API . Tuttavia, i dati del tuo negozio dovrebbero guidare ogni impostazione.
8. Esempio: Sincronizzazione di un catalogo prodotti di grandi dimensioni
Immaginate un processo che scarica i dettagli completi di ogni prodotto. Avvia molti processi e non salva alcun progresso. Una richiesta va in timeout, quindi l'intero processo ricomincia da capo. A quel punto scarica gli stessi prodotti senza modifiche, sovraccaricando ulteriormente il sistema.
Un processo migliore utilizza una dimensione di pagina collaudata e richiede solo i campi necessari. Memorizza ogni pagina e salva un punto di controllo. La pagina successiva inizia quando la capacità è disponibile.
Dopo un errore di breve durata, il processo lo registra e attende. In caso di risposta 429, vengono visualizzati i dettagli validi per il tentativo di ripetizione. Le esecuzioni successive recuperano solo i record modificati, se supportato. Un controllo completo pianificato può individuare gli aggiornamenti mancanti.
Questo design potrebbe inviare un numero inferiore di chiamate al secondo. Tuttavia, spesso si conclude in modo più affidabile perché il lavoro è costante e facile da riprendere.
9. Realizza un'integrazione PrestaShop più affidabile
Una corretta gestione dei limiti di frequenza delle API di PrestaShop inizia con la raccolta di prove. Individua il livello che applica il limite. Quindi, valuta se hai troppe chiamate, troppi dati o entrambi.
Utilizza la paginazione e i campi selezionati per mantenere ogni risposta di dimensioni ridotte. Aggiungi sincronizzazioni basate sulle modifiche, una gestione accurata della cache e limiti al numero di worker per ridurre il traffico. Infine, utilizza log, monitoraggio e tentativi limitati in modo che gli errori siano chiari e il ripristino sicuro.
Prima di scalare una sincronizzazione, esamina le opzioni del servizio web per la tua versione di PrestaShop. Testa l'intero processo con dati realistici. Nella maggior parte dei casi, un processo di piccole dimensioni che può essere ripreso è più sicuro di un'unica richiesta di grandi dimensioni.
Per soluzioni PrestaShop affidabili, sviluppo di app iOS e Android, modifiche personalizzate e migrazioni di siti web, i proprietari di negozi possono contattarci all'indirizzo [email protected] . I proprietari di negozi possono anche contattarci tramite il nostro servizio di assistenza.
