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 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!
Rails job and your application’s job is to serve the user request.
Whatever your app does.
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.
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.”
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:
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! 🙂