12

If I have a server with 1 core, how many puma workers, threads and what database pool size is appropriate?

What's the general thumb here?

SandeliusME
  • 802
  • 1
  • 10
  • 19

1 Answers1

12

Not an easy answer.

The two main sources of information are:

  1. Puma github repository (the authors' point of view)
  2. Heroku's web page (the main big user's point of view)

Unfortunately they are inconsistent mostly because heroku has different deployment metrics and terminology.

So I ended up following the puma repository guidelines which says:

  • One worker per core
  • Threads to be determined in connection with RAM availability and application and
  • Threads = Connection Pool

So the number of threads is mostly a try and check operation.

tommasop
  • 18,495
  • 2
  • 40
  • 51
  • 2
    The 'One worker per core' guideline gets thrown around a lot, but it's basically the opposite of what Heroku says (they state RAM as the only limiting factor for workers, and suggest threads should be tied to available processor). Has anyone given the final word on this yet? Heroku's version makes more sense to me, intuitively. – robomc Nov 23 '15 at 00:54
  • 3
    As I understand it, the real benefit of workers with Puma is parallelism, since they're separate ruby processes. If you only have 1 core, there's really no reason to use more than 1 worker, as they can't run in parallel. That said, Heroku may have discovered some other efficiency improvements of using multiple workers even in a single core environment. – Chris Hall Jul 11 '16 at 17:16
  • You are perfectly right and I've put it as part of the guidelines: One worker per core ;) – tommasop Jul 11 '16 at 21:08
  • Am I correct in assuming that a 'core' is the same thing as a heroku dyno? – Matt Sep 10 '16 at 15:24
  • 2
    In single core environment I noticed big delays with multiple process. – GorillaApe Nov 01 '16 at 07:06
  • 1
    Tested my app yesterday on one Heroku free dyno. 100 requests sent gave the results: 1 thread, 3 workers => Medium request time: 1000ms. 3 threads, 1 worker => Medium request time: 3400ms. So on heroku I would go for more workers and less threads on the cheaper dynos at least. Of course, best is to load test your specific app. – Robban Nov 30 '16 at 22:48
  • When scaling out, the formula Threads = Connection Pool can be a waste of connections (Postgresql has a limit of some hundreds on `max_connections`). I think it may be ok to keep the connection pool slightly lower then the number of threads (the thread doesn't use the connection all the time). – collimarco Jul 30 '17 at 14:10
  • 3
    In my personal experience 1 worker per core is not enough: I suggest 1.5 or 2 workers per core. Otherwise when the Ruby process is blocked on I/O or similar you waste some CPU. – collimarco Sep 14 '19 at 16:04
  • Maybe it could be that increasing core power will allow for multiple workers per core – tommasop Sep 16 '19 at 06:01