Qual è il numero massimo di connessioni cURL impostato da?

Question

Ho uno script che esegue 1000 richieste CURL utilizzando le funzioni curl_multi_ * in PHP.

Qual è il ritardo del collo di bottiglia?

Potrebbe essere l'utilizzo della CPU? C'è un modo più efficiente, in termini di come quel numero di connessioni in uscita è gestito dal server, per fare questo?

Non riesco a modificare la funzionalità e le richieste stesse sono semplici chiamate a un'API remota. Mi chiedo quale sia il limite: avrei bisogno di aumentare la memoria sul server, o sulle connessioni Apache o sulla CPU? (O qualcos'altro che ho perso)

Answer 1

Le vostre richieste vengono fatte in un singolo thread di esecuzione. Il collo di bottiglia è quasi certamente CPU, hai mai visto effettivamente eseguire il ricalcolo del codice multiuso? ... è incredibilmente affamato di cpu; perché non hai abbastanza controllo sulla gestione delle richieste. curl_multi ti consente di orchestrare 1000 richieste contemporaneamente, ma non è una buona idea. Non hai quasi nessuna possibilità di usare curl_multi in modo efficiente perché non puoi controllare il flusso di esecuzione in modo abbastanza preciso, solo la manutenzione dei socket e select() su di essi renderà conto dell'elevato utilizzo della CPU che vedresti guardando il tuo codice eseguito su la riga di comando.

I motivi per cui l'utilizzo della CPU è elevato durante tali attività è questo; PHP è progettato per funzionare per una frazione di secondo, fare tutto il più velocemente possibile. Di solito non importa come viene utilizzata la CPU, perché è per un breve lasso di tempo. Quando si prolunga un'attività come questa il problema diventa più evidente, l'overhead dovuto a ogni opcode diventa visibile al programmatore.

Sono consapevole che hai detto che non è possibile modificare l'implementazione, ma ancora, per una risposta completa. Tale compito è molto più adatto per Threading di ricciolo più, e si dovrebbe iniziare a leggere http://php.net/pthreads, a partire da http://php.net/Thread

Lasciato a se stessi su una CPU inattiva anche 1000 le discussioni sarebbero consumare tanto CPU come curl_multi, il punto è che puoi controllare con precisione il codice responsabile del download di ogni byte di risposta e caricare ogni byte della richiesta, e se l'utilizzo della CPU è un problema puoi implementare un processo "carino" chiamandoci esplicitamente o limitando l'utilizzo della connessione in modo significativo Inoltre, le vostre richieste possono essere riparate in thread separati.

Non suggerisco che 1000 thread è la cosa da fare, è più che probabile che non sia. La cosa da fare sarebbe progettare un Stackable (vedi la documentazione) il cui compito è quello di fare e servire una richiesta in un modo "bello" ed efficiente, e progettare pool (vedi esempi su github/fonti di estensione pecl) dei lavoratori per eseguire il tuo richieste di nuova concezione ...