Method: ActionCable::Server::Base#worker_pool — Documentation for actioncable (6.0.2.1)

  • Ensure that your database connection pool size is as least as large as your worker pool size. 
  • Otherwise, workers may oversubscribe the database connection pool and block while they wait for other workers to release their connections.

The worker pool is where we run connection callbacks and channel actions. We do as little as possible on the server's main thread. The worker pool is an executor service that's backed by a pool of threads working from a task queue. The thread pool size maxes out at 4 worker threads by default. Tune the size yourself withconfig.action_cable.worker_pool_size.

Using Active Record, Redis, etc within your channel actions means you'll get a separate connection from each thread in the worker pool. Plan your deployment accordingly: 5 servers each running 5 Puma workers each running an 8-thread worker pool means at least 200 database connections.

Also, ensure that your database connection pool size is as least as large as your worker pool size. Otherwise, workers may oversubscribe the database connection pool and block while they wait for other workers to release their connections. Use a smaller worker pool or a larger database connection pool instead.

=> Comment: if worker pool size is larger than db connection pool size. For example: db pool is 10 and worker pool is 11. So it always subscribes 11 connections to db. No available connection overtime. "Subscribe" here means it separate 11 connections from each threads and put them to 11 worker pool to execute. Unluckily, db connection pool is only 10.