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 Sinatra.
What happens then?
Your browser connects to
localhost, on port
3000, where a Ruby application server like Puma is waiting.
localhostpoints 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?
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.
But 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 Puma itself.
Why would you want to choose Puma over other servers?
The main reason they mention is, that if you use Unicorn – an alternative app server – you are susceptible to slow client attacks.
Puma is 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.”
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! 🙂