What’s this “Puma” thing that starts running when you do
It’s an app server!
Let me explain what an application server is & why do we need them with an example.
Understanding App Servers
Let’s say you start building your new shiny web application in Ruby.
And before you write any code…
You want to see it load in your browser, even if just to see the default “welcome” page.
So you open your browser, you point it at
localhost:3000, or maybe
localhost:4567 if you’re using
What happens then?
Your browser connects to
3000, where a Ruby application server like
Puma is waiting.
localhost points to a special IP address,
127.0.0.1, which always refers to your computer
The job of Puma, or any other
rack-based server (like Thin / Unicorn), is to handle the browser’s request & pass it along to your application through a common interface.
Which interface are we talking about?
Rack in detail in another article.
Back to Puma.
Why do we use an app server, instead of having Rails directly handle requests?
We do this because it allows for a fundamental software design principle.
Separation of concerns!
Understanding Separation of Concerns
Rails job and your application’s job is to serve the user request.
Create a new account
Check if login credentials are valid
Show a product page where you can buy a 100% cacao chocolate bar
Whatever your app does.
Rails offers the menu of things a user can do, but it’s also the chef, it gets things done
Puma is the waiter, it takes orders & forwards them to the kitchen
Having things set up this way allows everyone to do their best.
Not only that…
It also allows you to switch the chef to Sinatra, or the waiter to Thin!
“When concerns are well-separated, there are higher degrees of freedom for module reuse as well as independent development and upgrade.”
Depending on your situation & preferences.
Application Server vs Web Server (Nginx & Apache)
At this point, you may be wondering…
How is a web server like Apache or Nginx different from a Ruby server?
Why can’t we use these two servers?
There is a big difference.
Nginx is a general webserver, it handles a request & if there is a matching file for that request it will return that file.
Nginx doesn’t know anything about Rack, or Ruby.
That’s why we need Puma or any other Rack-compatible web server.
Using Nginx in production can still be helpful.
Nginx can handle connections more effectively & it can serve static assets (css & js files) without having to forward the request to your application.
Now that we understand what an application server is & why it’s useful.
We can look at
Why would you want to choose Puma over other servers?
Heroku’s recommended server.
The main reason they mention is, that if you use Unicorn – an alternative app server – you are susceptible to slow client attacks.
multi-threaded, which usually results in less memory usage.
“The operating system performs less work on behalf of a multithreaded program than it does for a multiprocess program. This translates into a performance gain for the multithreaded program.”
PThreads Programming Which Server Is Faster?
Running a simple Rack app with this command:
rackup -s thin rack-simple.ru 2>1 &>/dev/null
Tested with this:
wrk -d 20 http://localhost:9292
I got these benchmark results:
Webrick 229.97 request/second
Thin 773.20 request/second
Puma 2035.34 request/second
Out of these three, it looks like Puma gets you the best performance.
But that won’t matter if you have a slow SQL query, or if you’re looping through arrays with millions of elements on every request.
You learned about application servers in Ruby, like Puma & Thin, so you now have a better understanding of why we use them.
Which one are you going to use for your next project?
Thanks for reading! 🙂