Puma is a fast, multi-threaded Ruby web-server used to host Rack applications such as Sinatra or Rails. Unlike Unicorn which follows the multi-process model, Puma makes use of multi-threaded architecture which has less memory overhead and hence improved performance. To best utilize Puma’s multi-threading capabilities it is advised to use it on a true multi-threading runtime such as JRuby.
In this article, I’ll walk you through how you can set up a Rails 3.2 app with Puma. I’ll be using Puma 2.0.1 version for this article. This guide assumes that you already have a Rails app to work with.
Add the Puma Gem in your Gemfile
For certain reasons that I cannot recall right now, I think I had to add the Gem up higher in the gems list, right after the rails gem. Also, if you are using any other web-servers such as Thin. Now is a good time to remove those.
Edit your script/rails file to add the new Rack handler
Notice, In this following change, I’ve added only lines 4 and 5.
Restart your Application.
Now, your app must be riding on the Puma server.
As part of this article, I’ll list the most simple possible steps to deploy this app on a VPS and I’ll be using Git for this. Since, different folks have different preferences for deployments (like Capistrano, Chef, Puppet etc). I’ll leave it upto you to suit those to your own preferences and scenario.
- Push your app changes to a remote Git host, such as Github.
- Login/SSH into your VPS server where you’ll be deploying the app.
- Clone the Git repo you pushed in step 1 on your VPS.
- Rectify any dependencies that your project might have, such as Database, Redis instances, Memcache, Production keys/configs etc.
- Start your rails app using the following command from the shell. This will boot up your server in detached mode on port 80. This also boots your server in production environment. You can now visit your VPS public hostname or IP and you shall be served with your application.
┌─[user@vps-server] - [/var/www/app-name] - [2013-07-03 11:04:11]
└─ <git:(master✗)> rails s Puma -p 80 -d
Again, the deployment section above is a very naive approach to deploy apps but should be perfect for your one-off side projects. For your mission critical applications you might want to look at some scalable deployment strategies such as putting your app servers behind a load balancer, separating node concerns and roles such as app server, database server, background worker node etc. I might do a follow up post on how to scale your architecture and put these app servers behind an Nginx reverse proxy.
If you liked this article and would like me to keep writing more of such articles, Let me know in the comments.