a) ¿Necesito la configuración before_fork / after_fork como en Unicornio, ya que los trabajadores del clúster están bifurcados?.
Normalmente no, pero como estás usando preload_app , sí. La precarga de la aplicación pone en marcha una instancia y luego bifurca el espacio de memoria para los trabajadores; el resultado es que sus inicializadores solo se ejecutan una vez (posiblemente asignando conexiones db y demás). En este caso, su on_worker_boot el código es apropiado. Si no estás usando preload_app , luego cada trabajador se inicia solo, en cuyo caso sería ideal usar un inicializador para configurar la conexión personalizada como lo está haciendo. De hecho, sin preload_app , su on_worker_boot block fallaría porque en ese momento ActiveRecord y los amigos ni siquiera están cargados.
b) ¿Cómo ajusto mi conteo de subprocesos dependiendo de mi aplicación? ¿Cuál sería la razón para dejarlo caer? / ¿En qué casos haría una diferencia? ¿No está ya optimizado el 0:16?
En Heroku (y mis pruebas), lo mejor es hacer coincidir su min /max subprocesos, con max <=DB_POOL entorno. El min los subprocesos permiten que su aplicación reduzca los recursos cuando no está bajo carga, lo que normalmente es excelente para liberar recursos en el servidor, pero probablemente sea menos necesario en Heroku; que Dyno ya se dedica a atender solicitudes web, también puede tenerlas listas. Mientras configura su max subprocesos <=su DB_POOL la variable de entorno no es necesaria, corre el riesgo de consumir todas las conexiones de su base de datos en el grupo, entonces tiene un subproceso que desea una conexión pero no puede obtenerla, y puede obtener el antiguo "ActiveRecord::ConnectionTimeoutError - could not obtener una conexión a la base de datos en 5 segundos". error. Sin embargo, esto depende de su aplicación, muy bien podría tener max> DB_POOL y estar bien Yo diría que tu DB_POOL debe ser al menos igual que su min el valor de los subprocesos, aunque sus conexiones no se cargan con entusiasmo (los subprocesos 5:5 no abrirán 5 conexiones si su aplicación nunca llega a la base de datos).
c) La base de datos Heroku permite 500 conexiones. ¿Cuál sería un buen valor para DB_POOL según el recuento de subprocesos, trabajadores y dinamómetros? - ¿Cada subproceso por trabajador por banco de pruebas requiere una única conexión de base de datos cuando se trabaja en paralelo?
El nivel de producción permite 500, para ser claro :)
Cada subproceso por trabajador por banco de pruebas podría consumir una conexión, dependiendo de si todos intentan acceder a la base de datos al mismo tiempo. Por lo general, las conexiones se reutilizan una vez que se realizan, pero como mencioné en b) , si sus hilos son más grandes que su grupo, puede pasar un mal momento. Las conexiones se reutilizarán, todo esto lo maneja ActiveRecord, pero a veces no de manera ideal. A veces, las conexiones quedan inactivas o mueren, y es por eso que se sugiere encender el Reaper, para detectar y recuperar conexiones muertas.
