Why Do We Need Application Servers in Ruby? (Like Puma)

3 years ago
/ By Jesus Castello
/ 7 COMMENTS

What’s this “Puma” thing that starts running when you do rails server?

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.

localhost points to a special IP address, 127.0.0.1, which always refers to your computer

Now:

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.

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! 🙂