2016-03-19 45 views
8

Usiamo il sedano per effettuare chiamate http di terze parti. Abbiamo circa 100+ attività che chiamano semplicemente le chiamate API HTTP di terze parti. Alcune attività chiamano le API in blocco, ad esempio mezzo milione di richieste alle 4 del mattino, mentre alcune sono continue chiamate API che ricevono richieste quasi una o due volte al secondo.Ottimizzazione di Celery per chiamate HTTP di terzi

La maggior parte dei tempi di risposta alle chiamate API è compresa tra 500 e 800 ms.

Stiamo vedendo tassi di consegna molto lenti con il sedano. Per la maggior parte delle attività di cui sopra, la velocità massima di consegna è di circa 100/s (max) a quasi 1/s (min). Credo che questo sia molto povero e qualcosa è decisamente sbagliato, ma non sono in grado di capire di cosa si tratta.

Abbiamo iniziato con un cluster di 3 server e ne abbiamo fatto un cluster di 7 server, ma senza miglioramenti. Abbiamo provato con diverse impostazioni di concorrenza da scala automatica a fisso 10, 20, 50, 100 lavoratori. Non ci sono backend di risultati e il nostro broker è RabbitMQ.

Poiché il tempo di esecuzione del nostro task è molto piccolo, meno di un secondo per la maggior parte, abbiamo anche provato a rendere il numero di prefetch illimitato a vari valori.

--time-limit=1800 --maxtasksperchild=1000 -Ofair -c 64 --config=celeryconfig_production

server sono 64 G RAM, Centos 6.6.

Puoi darmi un'idea di cosa potrebbe essere sbagliato o di indicazioni su come risolverlo?

Dovremmo andare con i gevents? Anche se non ho idea di cosa sia.

+0

Quanto sono piene le code in RabbitMQ? RabbitMQ è più veloce quando le code sono vuote. È possibile monitorare l'utilizzo della CPU della macchina RabbitMQ. Se si vede un forte utilizzo della CPU, probabilmente, è perché RabbitMQ sta facendo molto per far fronte alle enormi dimensioni della coda. – LearnerEarner

+1

Potrebbe sembrare sciocco e sicuramente hai prestato attenzione a questo ma hai controllato se il server di terze parti si sta comportando bene sotto carico? Sta ancora rispondendo a 500-800 ms anche quando lo colpisci con molte richieste simultanee? – LearnerEarner

+0

http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/ – LearnerEarner

risposta

5

Prima di tutto - GIL - non dovrebbe essere un caso, poiché più macchine dovrebbero andare più veloci. Ma - per favore controlla se il carico va solo su un core del server ...

Non sono sicuro che nel tuo caso l'intero Celery sia una buona idea. Questo è un ottimo software, con molte funzionalità. Ma, se questo non è necessario, è meglio usare qualcosa di più semplice - nel caso in cui alcune di queste funzionalità interferiscano. Vorrei scrivere un piccolo PoC, controllare altri software client, come il pika. Se ciò non fosse d'aiuto, il problema è con l'infrastruttura. Se aiuta - hai una soluzione. :)

È davvero difficile dire cosa sta succedendo. Può essere qualcosa con IO, o troppe chiamate di rete ... Vorrei fare un passo indietro - per scoprire qualcosa che funziona. Scrivi test di integrazione, ma assicurati di utilizzare 2-3 macchine solo per utilizzare lo stack tcp completo. Assicurati di avere CI e esegui i test una volta al giorno o giù di lì per vedere se le cose vanno nella giusta direzione.

+0

Anche in alcuni casi specifici GIL non rilascia dopo 100 ms –