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.
Configuring Nginx
Common config
You probably already have this setted up if you were using Nginx / Unicorn stack but here is a quick reminder for Nginx global configuration:
/etc/nginx/nginx.conf
Pretty straigth forward, nothing new here.
Vhost file
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.
Configuring Puma
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.
Configuring Capistrano
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.
Share on
Twitter Facebook LinkedInHave comments or want to discuss this topic?
Send an email to ~bounga/public-inbox@lists.sr.ht