How to determine the optimal number of Puma workers when there are multiple Rails application in one server?

[fireva]

I have a server with four CPU cores and two rails applications served with Puma web server. I've done some research and found out that for multithreaded case, I am supposed to set the number of workers equal to the number of CPU cores available. I assume this setting is for one application per server. If there are two applications on my server, should I set four worker for both application or should I divide the CPU core for each app and set two worker per application?

I hope someone can help me with what is the optimal choice and explain the reason behind it.

[nateberkopec]

The optimal number is always 1 Puma worker process per 1 CPU core, then tune thread count so that the CPU core is well-utilized at maximum load.

So, if I have 4 cores and 2 applications, I would configure 2 workers for the first application and 2 workers for the second application.

[fireva]

Okay, I get it. Thanks for the answer! It's really helpful.

[rzepetor]

@nateberkopec so there is no sense to set 2 workers when there is one core? Heroku docs says:

https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#recommended-default-puma-process-and-thread-configuration

so they recommends 2 workers on instance with one core if there is enough RAM, this make any sense?

[nateberkopec]

The only time you should run more than 1 worker per core is if you are running with 1 thread in the threadpool (e.g. threads 1,1)

Heroku is a special case. As their chart says, you are not actually getting 1 vCPU - it is "n/a". That's because eco/basic/standard dynos on Heroku are actually cpu-timesliced across 8 vCPUs (not guaranteed, this is just how it is implemented last time I checked). So on Heroku, their advice makes sense, because there is actually more than 1 logical core available.

[9mm]

@nateberkopec this is extremely helpful... I have 2 dumb questions...

1. I'm assuming on Amazon EC2 I should look at "CPU Core" and not "vCPU Core" right? Im looking at m5.large and there seems to be only 1 core

2. So with 1 rails app running, my memory is very low (after tuning max threads). Is this just wasted memory that I can't utilize by adding another process? Im assuming the answer is no, as that conflicts with your advice, I am just wondering why, or if this is acceptable.
   Thanks!

[MaloTheCat]

As you said, to set the number of worker -> 1:n /app where n is equal to CPU core and the whole divided by number of running applications.
Maybe dumb question but what "applications" stands for? Does "services" count? If I have a Web app on Rails, a queue job like Sidekiq, a Broker for Mqtt I/O, a web server like Sinatra and all of that are running through HA managed by Kubernetes -> how to set the right numbers of Puma workers?
I supposed that everything that doesn't run a "bundle exec rails server" sentence like are just third party services and doesn't count.

[9mm]

when he says applications hes talking about WEB_CONCURRENCY which sets the number of workers in the puma config:

if ENV["RAILS_ENV"] == "production"
  worker_count = Integer(ENV.fetch("WEB_CONCURRENCY") { Concurrent.physical_processor_count })
  workers worker_count if worker_count > 1
else
  workers 2
end

Each worker holds an entire copy of your application in memory, which is why he said that. And your WEB_CONCURRENCY should be set to number of CPU cores, or in some cases on Heroku, maybe 1 or 2 more than the number of cores.

[MaloTheCat]

Thank you for the answer!