Prestazioni push di lavoro insoddisfacenti con Python RQ

Question

Provare a utilizzare python-rq per supportare il back-end della nostra applicazione Web, ma l'inserimento di nuovi lavori richiede molto tempo - fino a 12 secondi.

Il colpo di prestazioni si verifica quando si esegue la chiamata di funzione enqueue_call, in particolare quando aumenta il numero di processi di lavoro connessi al sistema (oltre 200).

il sistema funziona nel modo seguente:

1. L'anteriore spinge lavori al server di coda compito. Questo usa la funzione enqueue_call per passare argomenti al lavoro (come timeout e ttl), oltre agli argomenti effettivi alla funzione da eseguire.
2. Più processi (distribuiti su più macchine) sono lavoratori in esecuzione, ciascuno sotto UNIX screen. I lavoratori seguono lo schema fornito nella documentazione, eseguendo la funzione di ciclo infinito Worker.work() per l'ascolto sulle code.
3. Durante l'elaborazione, alcune attività ne generano di nuove, di solito nella stessa coda su cui sono in esecuzione.

Circa le infrastrutture:

• Il server Redis che gestisce questa coda compito è dedicato ad esso. Inoltre, la persistenza è disabilitata. È in esecuzione su un server Rackspace da 4 GB.
• Quando si esegue redis-benchmark sul server con la coda delle attività, otteniamo risultati superiori a 20000 r/s in media per la maggior parte dei benchmark.

Come possiamo migliorare le prestazioni di spinta per nuovi lavori in una situazione come questa? C'è uno schema migliore che dovremmo usare?

Answer 1

12 secondi? Questo è folle.

Hai mai pensato di usare il sedano?
Non utilizzato mai redis-rq, ma da quello che vedo basato su documenti non è veramente buono per un grande numero di lavoratori
La coda di Redis è solitamente basata sul comando BLPOP, che può funzionare con più client, ma chissà quanto può davvero gestire per una chiave.

Quindi vi consiglio di passare al sedano o scrivere il proprio distributore di compiti per python-RQ, che non sarà più facile poi passare