Sto lavorando su un sito con un volume di traffico piuttosto elevato (>150K visualizzazioni di pagina/giorno). Sto ricevendo alcuni errori 429, per lo più sul message bus. In precedenza avevo alcuni problemi dovuti a una configurazione errata di set_real_ip_from, ma questo è stato risolto. Ho anche rimosso (forse temporaneamente?) il template di limitazione della frequenza.
Sto ancora vedendo circa 0,5 errori 429 al secondo.
Ho 5 worker Unicorn con una CPU a 2 core/4 thread. 16 GB di RAM. Postgres è su un host separato. Le CPU rimangono per oltre il 50% inattive.
Ho rimosso il template di limitazione della frequenza e aumentato i worker Unicorn a 5 alle 8:20 circa.
È assolutamente normale: il message-bus ridurrà la frequenza con il codice 429 poiché i tuoi unicorni sono sotto forte carico e stanno accodando leggermente.
4 core con 16 GB di RAM è un rapporto davvero strano se il nodo non esegue il database. Ad esempio, 8/8 sarebbe meglio.
Ottimo! Grazie. La CPU è ancora sotto stress per l’elaborazione delle immagini, che spero verrà completata entro un giorno o due.
È vero. Ma il server bare metal ha 2 core/4 thread. È facile aggiungere RAM, non core (ne ho un altro a casa con 32 GB!). Ho separato il database e il web su due macchine per ottenere più potenza di calcolo. Ho una mezza dozzina di altri database di siti a basso traffico sullo stesso server database (web su un host diverso). Pensi che sarebbe meglio eseguire DB e web sulla stessa macchina? Perderei un po’ di CPU ma migliorerei la latenza, immagino.
Se hai la possibilità di bilanciare il carico, potresti provare a mettere i worker web su entrambe le macchine per il tuo sito ad alto carico, con meno su quello con il database, forse 5+2?
Se risolvere il problema spendendo è un’opzione, basta ottenere un altro host con un miglior rapporto CPU:RAM.
Beh, queste macchine, che ho ottenuto gratuitamente, stanno iniziando a mostrare i segni dell’età, quindi sto cercando di fare i conti con questa realtà: le prestazioni di una singola CPU sembrano comunque migliori rispetto a un droplet DO. Se risolvere il problema con i soldi nel breve termine fosse un’opzione, probabilmente non avrei questo cliente specifico che richiede prestazioni enterprise a prezzi da business.
Ma ho anche notato che avevo il numero di unicorni hard-coded da qualche altra parte nella catena, quindi sto ancora eseguendo solo 3.
Purtroppo, la mia configurazione attuale comunica con Docker solo su un singolo host. Dovrei dedicare un po’ più di tempo per vedere se riesco a far girare anche un paio di unicorni sull’altra macchina. Probabilmente è il momento giusto per guardare di nuovo HAproxy, ma ho un altro progetto che vorrei lanciare prima.
Grazie mille per il tuo contributo.
EDIT: E quando ho finalmente passato da 3 a 5 unicorni, i grafici delle prestazioni sembrano più o meno gli stessi (forse leggermente più lenti?), ma gli errori 429 sono diminuiti in modo significativo. Sembra che una volta completata l’elaborazione delle immagini, tutto funzionerà perfettamente.
E, solo un giorno dopo, gli errori 429 sono scesi quasi a zero, quindi il consiglio di Rafael “non preoccuparti” è stato brillante! Grazie ancora, Kane e Rafael. Non posso esprimere quanto apprezzi il vostro aiuto.
