a) Preciso da configuração before_fork / after_fork como inUnicorn, já que os Cluster workers são bifurcados?.
Normalmente não, mas como você está usando
preload_app , sim. O pré-carregamento do aplicativo coloca uma instância em execução e, em seguida, bifurca o espaço de memória para os trabalhadores; o resultado é que seus inicializadores são executados apenas uma vez (possivelmente alocando conexões de banco de dados e tal). Neste caso, seu on_worker_boot código é apropriado. Se você não estiver usando o preload_app , então cada trabalhador se inicializa; nesse caso, usar um inicializador seria ideal para configurar a conexão personalizada como você está fazendo. Na verdade, sem preload_app , seu on_worker_boot bloco iria dar erro porque nesse ponto ActiveRecord e amigos nem sequer são carregados.
b) Como faço para ajustar minha contagem de threads dependendo do meu aplicativo - qual seria o motivo para soltá-lo? / Em que casos faria diferença? O 0:16 já não está otimizado?
No Heroku (e nos meus testes), é melhor corresponder ao seu
min /max threads, com max <=DB_POOL contexto. O min threads permitem que seu aplicativo reduza os recursos quando não estiver sob carga, o que normalmente é ótimo para liberar recursos no servidor, mas provavelmente menos necessário no Heroku; que o dyno já está dedicado a atender a solicitações da web, também pode tê-los prontos e prontos. Ao definir seu max threads <=seu DB_POOL A variável de ambiente não é necessária, você corre o risco de consumir todas as suas conexões de banco de dados no pool, então você tem um thread querendo uma conexão, mas não consegue, e você pode obter o antigo "ActiveRecord::ConnectionTimeoutError - could not obter uma conexão de banco de dados em 5 segundos." erro. Isso depende do seu aplicativo, porém, você poderia muito bem ter max> DB_POOL e ficar bem. Eu diria que seu DB_POOL deve ser pelo menos igual ao seu min valor de threads, mesmo que suas conexões não sejam carregadas avidamente (os threads 5:5 não abrirão 5 conexões se seu aplicativo nunca atingir o banco de dados).
c) O banco de dados Heroku permite 500 conexões. Qual seria um bom valor para DB_POOL dependendo da contagem de threads, trabalhadores e dinamômetros? - Cada thread por trabalhador por dyno requer uma única conexão de banco de dados ao trabalhar em paralelo?
O Nível de Produção permite 500, para ser claro :)
Cada thread por trabalhador por dinamômetro poderia consomem uma conexão, dependendo se todos estão tentando acessar o banco de dados ao mesmo tempo. Normalmente as conexões são reutilizadas assim que terminam, mas como mencionei em
b) , se seus threads forem maiores que seu pool, você poderá ter um mau momento. As conexões serão reutilizadas, tudo isso é tratado pelo ActiveRecord, mas às vezes não é o ideal. Às vezes, as conexões ficam ociosas ou morrem, e é por isso que é sugerido ativar o Reaper, para detectar e recuperar conexões inativas. 
