passenger 5 performance compared to unicorn/thin/puma/etc
Asked Answered
F

4

8

I've been searching around for performance tests on the new passenger 5 as I read here it became way faster.

I tried to find other ressources confirming this but no luck. Has anyone tried to install it and see the difference?

Fart answered 8/7, 2015 at 15:28 Comment(1)
Welcome to Stack Overflow. Why don't you be the first to try it, and give us a summarization including benchmarks so we have hard data.Chauffeur
C
22

Passenger 5 scores better on custom-picked benchmarks because it has a built-in caching layer ("turbocaching") that can avoid actually running your application code for identical requests in a short timeframe; it will not make your actual application code run any faster. This caching layer is only active in certain constrained situations, and is not likely to provide much benefit in the vast majority of actual cases. If you aren't careful, the caching layer may actually end up breaking your application - I demonstrated several security vulnerabilities due to the caching layer to Phusion during the 5 beta phase (which they fixed, at the cost of the caching layer not being able to cache nearly as much). IMO, the Raptor/Passenger 5 benchmarks are deceptive marketing fluff, and the caching layer exists primarily to win Hello World benchmarks, and you should probably just ignore them.

That said, the speed of your application server is almost certainly insignificant in the scope of your overall application performance. Passenger is a great platform because it's extremely user-friendly, well-documented, has an absolutely fantastic installer, and handles a lot of the annoying crap for you out of the box. You should use Passenger if you need the functionality it provides and don't want to screw around with a ton of config stuff. If it doesn't fit your use case, use something else that does.

If every last microsecond is of prime concern to you, you should measure your application's performance under various webservers and various workloads, and then pick the one that performs the best. Otherwise, use whatever you like the most and then switch once performance becomes an actual problem.

Footnote: If you do use Passenger 5, be sure to read the Turbocaching security changes article to be sure you don't accidentally make your application vulnerable to user data theft (or otherwise introduce bugs) through the turbocaching layer.

Columbus answered 8/7, 2015 at 19:19 Comment(3)
Thank you for the great response Chris. I'm fairly new to the ruby world and don't know yet as much as I would like. I do agree each part of a server config must feat your use case. In my case, I'm running a small resume/portfolio app on the smallest droplet available at digital ocean. It has 512Mb of ram and it gets overloaded quite fast by the ruby process which takes around 350Mb of ram. This causes some problem with the DB since the server struggles to open new connections at some point. Regarding what @Olivier said Passenger might help me out here.Fart
Passenger is really great for that kind of stuff, because it works hard to try to share RAM between processes where possible. Puma with a single worker/multiple threads would be memory-friendly, too, though there are limitations on concurrency in the standard Ruby runtime (look up GIL/GVL if you want to know more). I would avoid pure forking servers like Unicorn if RAM is a prime concern.Columbus
Amazing response @ChrisHeald ! Thx for sharing ! I wasn't aware about that possible vulnerability !Harri
H
12

I recently migrated my app from Puma to Passenger. I have to say that I'm really happy about this move, especially because I'm hosting it on Heroku.

Since I updated to Ruby 2.2, I had some memory issues with Puma due to Heroku memory limitation (512M). I tried a couple of different configurations but without success. Since I moved to Passenger, I saw the memory usage go down to almost half what I was consuming with Puma with the same number of server instances (3 in my case).

Regarding the response time, it seems to be pretty much the same as before but with those memory improvements. Although, I reduced my number of Heroku dynos to handle the same number of requests.

In conclusion, on my personal experience, Passenger helped me a lot reducing the memory used by the app but it didn't helped improving the average response time. Another good point is, regarding the Heroku pricing, it helped me a lot to reduce the cost of my hosting.

I know this post is not really exhaustive without any benchmarks etc... But I thought that maybe you could find it interesting to have a personal experience on a migration from Puma to Passenger.

Hope it helps :)

Harri answered 8/7, 2015 at 18:48 Comment(1)
Thank you Olivier, this is what I was searching for to convince me to migrate to passenger. I'll try it out on my config and will let you know the benefits.Fart
N
6

First of all, let's just be clear, when we talk about server performance, the question is about how well the server scales as usage increases. If your server has one or very few human users, for most apps, you will get the same end-user experience regardless of which server you use because the bottle-neck will be the performance of Ruby, not the app server.


For medium and large apps:

So let's talk about scaling. The more CPU power and RAM you have, the more you can scale. Most servers run out of RAM faster than CPU power. So the key is to minimize the amount of RAM used per request. Each request the server receives will be handled by a process or a thread. Processes use a lot of RAM, threads use very little RAM. So the goal is simply to have lots of threads and few processes.

Puma and Passenger Enterprise are both multi-threaded servers which will scale approximately the same. (Passenger's benchmarks claim to use 5MB less RAM per process, but this is negligible.) Passenger itself (the free version) is single threaded and will not scale as well as the paid Passenger Enterprise version or as well as Puma.

So if you want maximum performance, you're choosing between Puma and Passenger Enterprise. The question then becomes, is Passenger Enterprise worth the financial cost vs is Puma worth the technical expertise cost. The answer depends on what's in your brain(s), what's in your bank account(s), and your general opportunity cost.

Passenger Enterprise has some nice tools that hold your hand if you're not an expert system administrator. Puma also has some tools but they are not as powerful as what Passenger Enterprise provides. Puma requires system-level expertise if you want to get the same control and insights as Passenger Enterprise. (You can also use Puma without all the bells-and-whistles of Passenger Enterprise, but I want to keep this comparison "apples-to-apples").

Personally, I'm a low-level guy who loves configuring servers so I prefer to trade my time rather than my money for an awesome Ruby server. Therefore, I use Puma. If you're not interested in configuring low-level stuff (or if you're a company that realizes software licenses are cheaper than administrator-developers), you might be better off with a paid Passenger Enterprise license.


For the guy running a $5 VPS (or similar low-resource, low-traffic environment):

What I said above is more for higher-traffic apps on servers with considerable resources. You're just trying to get by with basics, so it does not really apply to you.

Think of Puma and Passenger Enterprise as jumbo jets that can move a lot of people very fast. That's way more than your little app needs. What you really need is the server equivalent to a Honda Civic. For that, you should consider either the free version of Passenger or Thin. Use free Passenger if you want easy setup and decent tools. Use thin if you want similar performance but have a willingness to engineer the server.

In this case, I see no reason to use anything but free Passenger unless you are looking for a challenge.

Nahum answered 3/7, 2016 at 20:36 Comment(0)
S
2

As others said, Passenger by itself doesn't make your app faster per se. Passenger itself has become a lot faster in version 5, but the app server is only a part of the response time. If your app is slow, then it doesn't matter how fast Passenger itself is.

Having said that, Passenger differentiates itself from other app servers by actively helping you to make your app faster. Passenger's turbocache is one way through which Passenger helps you. The article Dynamic Site as fast as a Static Generated One with Raptor demonstrates a good use case for the turbocache. Passenger also provides an optimization guide that gives you tips on how to optimize your app using Passenger settings.

Slack answered 8/7, 2015 at 21:27 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.