When Rails 4 was released it offered a bunch new features and deprecations :
You can see that thread safety is since on by default so a Rack server can safely create threads for your Rails app rather than forking process and waste cpu cycles and memory.
If you didn’t switch to a Rack compatible server that can efficiently makes use of threads then it’s time to do so. I decided to switch from Unicorn (process forks) to Puma which is thread oriented.
You’ll see a great memory improvement if you switch and you’ll be able to use
threads effectively in your app if you want to since Rails is now fully thread-safe.
Here are the three steps to have a Nginx / Puma / Capistrano stack up & running for a Rails app.
You probably already have this setted up if you were using Nginx / Unicorn stack but here is a quick reminder for Nginx global configuration:
Pretty straigth forward, nothing new here.
For example /etc/nginx/sites-enabled/01-bounga
Once again nothing new here. You may have to change some values or add some directives depending on your app behaviour but this config example should work in most usecases.
Puma default settings are safe so you can use it in your Rails apps without even creating a config file. It will work just fine thanks to capistrano3-puma integration which we’ll talk about later.
Nonetheless maybe you’ll need to tweak your config so here are some insigths to be able to tune Puma behaviour. This is a very well documented example provided by Puma development team that you can put in config/puma.rb.
Note that you’ll be able to set most of these parameters right in your Capistrano config file, per environment which seems better to me.
Now we need to setup Capistrano to be able to handle Puma on deploys.
First you’ll need to add a gem to your Gemfile:
Then in your Capfile you’ll have to require it:
It will add some tasks to you Capistrano tasks:
Now we’re done! Everything else is handled for us. We can tweak the default behaviour but in most cases it will work as expected, for example bundle exec cap deploy will restart Puma for us at the end of the deploy.
Puma, a developer’s best friend
Puma seems to be the way to go these days if you want to use a proxy and a Rack server. It allows fast and effecient concurrency. Trust me you won’t regret this choice.