a) Ho bisogno della configurazione before_fork / after_fork come inUnicorn, dal momento che i cluster worker sono forkati?.
Normalmente no, ma dal momento che stai usando preload_app , sì. Il precaricamento dell'app rende un'istanza attiva e funzionante e quindi esegue il fork dello spazio di memoria per i lavoratori; il risultato è che i tuoi inizializzatori vengono eseguiti solo una volta (possibilmente allocando connessioni db e simili). In questo caso, il tuo on_worker_boot il codice è appropriato. Se non stai utilizzando preload_app , quindi ogni lavoratore si avvia da solo, nel qual caso l'utilizzo di un inizializzatore sarebbe l'ideale per configurare la connessione personalizzata come stai facendo. Infatti, senza preload_app , il tuo on_worker_boot blocco si verificherebbe un errore perché a quel punto ActiveRecord e gli amici non vengono nemmeno caricati.
b) Come posso regolare il conteggio dei thread in base alla mia applicazione:quale sarebbe il motivo per eliminarlo? / In quali casi farebbe la differenza? 0:16 non è già ottimizzato?
Su Heroku (e sui miei test) è meglio che corrisponda al tuo min /max thread, con max <=DB_POOL collocamento. Il min threads consente alla tua applicazione di ridurre le risorse quando non è sotto carico, il che normalmente è ottimo per liberare risorse sul server, ma probabilmente meno necessario su Heroku; che dyno è già dedicato a servire le richieste web, potrebbe anche averle aperte e pronte. Durante l'impostazione del tuo max thread <=il tuo DB_POOL la variabile di ambiente non è richiesta, corri il rischio di consumare tutte le connessioni al database nel pool, quindi hai un thread che desidera una connessione ma non riesci a ottenerla e puoi ottenere il vecchio "ActiveRecord::ConnectionTimeoutError - Impossibile ottenere una connessione al database entro 5 secondi." errore. Questo dipende dalla tua applicazione però, potresti benissimo avere max> DB_POOL e stare bene. Direi il tuo DB_POOL dovrebbe essere almeno uguale al tuo min valore dei thread, anche se le tue connessioni non vengono caricate avidamente (i thread 5:5 non apriranno 5 connessioni se la tua app non raggiunge mai il database).
c) Il database di Heroku consente 500 connessioni. Quale sarebbe un buon valore per DB_POOL a seconda del conteggio di thread, worker e dyno? - Ogni thread per lavoratore per banco prova richiede una sola connessione DB quando si lavora in parallelo?
Il livello di produzione consente 500, per essere chiari :)
Ogni thread per lavoratore per banco prova potrebbe consumano una connessione, a seconda che stiano tentando tutti di accedere al database contemporaneamente. Di solito le connessioni vengono riutilizzate una volta terminate, ma come ho detto in b) , se i tuoi thread sono più grandi del tuo pool puoi passare un brutto momento. Le connessioni verranno riutilizzate, tutto questo è gestito da ActiveRecord, ma a volte non idealmente. A volte le connessioni diventano inattive o muoiono, ed è per questo che si suggerisce di accendere il Mietitore per rilevare e recuperare le connessioni morte.
