Qual è la differenza tra Worker e Thread in Puma

Question

Qual è la differenza tra un puma worker e un thread puma nel contesto di un dungeo di heroku?

Quello che so (per favore correggetemi se sbaglio):

• Thin non è concorrente, quindi un processo web può fare solo una richiesta alla volta

• In unicorno, ho so che posso avere diversi lavoratori di unicorno in un unico processo per aggiungere concorrenza.

Ma in puma ci sono discussioni e lavoratori .. Non è un lavoratore un filo nel processo di puma?

Posso utilizzare più worker/thread per aggiungere la concorrenza Web in Heroku?

Answer 1

Come dice l'altra risposta, questo Heroku article è abbastanza buono con le spiegazioni di alcuni elementi di configurazione.

Tuttavia, se è necessario regolare la propria applicazione su Heroku o in qualsiasi altro punto, è necessario sapere come funzionano le cose.

Penso che tu sia quasi corretto quando dici "un lavoratore è un thread all'interno del processo puma", credo che un lavoratore sia un processo a livello di sistema operativo biforcato da puma che quindi può utilizzare i thread internamente.

Per quanto ho capito, puma eseguirà il processo del sistema operativo tutte le volte che si imposta tramite la configurazione workers per rispondere alle richieste http. Questo ti dà il parallelismo in termini di gestione di più richieste, ma di solito occuperà più memoria poiché "copierà" il codice dell'applicazione per ciascun lavoratore.

Ogni puma worker utilizzerà quindi più thread all'interno del processo del sistema operativo in base alla configurazione threads. Questi aggiungono la concorrenza consentendo al processo puma di rispondere a più richieste in modo tale che, se un thread è bloccato, cioè elaborando una richiesta, può gestire una nuova richiesta con un altro thread. Come detto, ciò richiede che l'intera applicazione sia protetta da thread, in modo tale che, ad esempio, qualsiasi configurazione globale da una richiesta non "perdite" in un'altra.

Si sintonizza Puma in modo che il numero di lavoratori fosse adeguato per il numero di CPU e memoria disponibili e quindi ottimizzare i thread in base a quanto si vorrebbe saturare l'host che esegue l'applicazione e come si comporta l'applicazione - altro non sempre equivale più veloce/più richiesta di throughput.

Answer 2

Si tratta di una grande area e io non sono un esperto, però ...

Puma può generare molti lavoratori, e ogni lavoratore può utilizzare molti thread per elaborare la richiesta.

L'unicorno non ha thread per quanto ne so, ha solo il modello di lavoro.

Se si utilizzano i thread, è necessario assicurarsi che il codice sia sicuro. Ciò significa Rails, qualsiasi gemma su cui fai affidamento e il tuo codice personale.

Per prestazioni ottimali, è inoltre possibile esaminare JRuby o Rubinius con supporto thread appropriato. La risonanza magnetica è limitata dal suo GIL.

C'è uno good article on Heroku che spiega come Puma utilizza worker e thread. Probabilmente dovresti leggerlo e ignorarmi :)