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
Now:
Which interface are we talking about?
Rack.
I explain Rack in detail in another article.
Back to Puma.
Why do we use an app server, instead of having Rails directly handle requests?
Great question.
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.
For example:
- 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.”
Wikipedia
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.
However…
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.
Understanding Puma
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?
First:
It’s 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.
Also:
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.”
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.
Summary
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!
The post Why Do We Need Application Servers in Ruby? appeared first on RubyGuides. Don't miss your free gift here :)
