61–70 of 86 posts
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. We've recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... The comparison covers things like concurrency models, I/O models, security, clustering, multi-app support,…
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. We've recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... The comparison covers things like concurrency models, I/O models, security, clustering, multi-app support,…
Please stop making your comparisons sound as if passenger-free was a fully functional application server such as unicorn or puma. It is not. Passenger-free is a deliberately crippled demo-version. If someone wants to use passenger in production they will have to pay $50 USD per year, per server for it. And you know that very well. The 'free' passenger drops requests and serves 502 errors to the users during every sin…
Earlier quoted context omitted.
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. What you said is basically correct. And yes, it is possible to combine event loops with threads in the way you described to get CPU concurrency as well. Whether it is actually helpful depends on the use case. The Phusion Passenger core is evented (similar to Nginx and Node.js) sin…
How does Passenger deal with blocking I/O from applications if it is single threaded? Does the entire event loop block while doing I/O?
Is it just me beeing blind, or does it not support https?
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. We've recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... The comparison covers things like concurrency models, I/O models, security, clustering, multi-app support,…
Please stop making your comparisons sound as if passenger-free was a fully functional application server such as unicorn or puma. It is not. Passenger-free is a deliberately crippled demo-version. If someone wants to use passenger in production they will have to pay $50 USD per year, per server for it. And you know that very well. The 'free' passenger drops requests and serves 502 errors to the users during every sin…
I've been using Passenger since it was called Apache mod_rails http://www.concept47.com/austin_web_developer_blog/ruby-on-r... you have to remember that before the Phusion guys showed up, there was no easy way to run a rails server without proxying requests to mongrel, thin or something like that. instances could bloat in memory or die and your app could, for whatever reason, go down and you wouldn't know it. Did I mention that rails apps were also pretty slow back then?
They made deploying and maintaining rails an order of magnitude easier with Passenger, first with the mindblowingly simple installation process and later by introducing ideas like killing and spinning up new app instances after xxx requests, or spinning instances up or down depending on activity. All this with simple configuration switches out the box. Even the advances in Passenger 4 are pretty amazing (threaded mode, and out-of-band garbage collection, come to mind)
What I'm saying is, they've done a lot for the Rails ecosystem and while I'm not a fan of their new pricing strategy with Passenger or their marketing tack with Puma posts on this thread, I think its worthwhile to be a bit more gentle in chiding them because of their peerless contributions in the past ... plus their link is actually a very well written comparison
Earlier quoted context omitted.
Please stop making your comparisons sound as if passenger-free was a fully functional application server such as unicorn or puma. It is not. Passenger-free is a deliberately crippled demo-version. If someone wants to use passenger in production they will have to pay $50 USD per year, per server for it. And you know that very well. The 'free' passenger drops requests and serves 502 errors to the users during every sin…
I think thats a little harsh. I've been using Passenger since it was called Apache mod_rails http://www.concept47.com/austin_web_developer_blog/ruby-on-r... you have to remember that before the Phusion guys showed up, there was no easy way to run a rails server without proxying requests to mongrel, thin or something like that. instances could bloat in memory or die and your app could, for whatever reason, go down and…
I don't see how their standing in 2008 excuses them to use shady trojan horse sales tactics to push their rather mediocre product in 2013.
Earlier quoted context omitted.
We just moved our ruby apps (puppet, Redmine,gitlab) from apache passenger to puma + nginx because passenger is awful - it's slow, bloated and it eats memory.
Ok sorry I re-read that and I sounded quite loaded, I was actually a bit miffed that someone from passenger posted on this puma thread but I suppose they have the right to. We didn't have a great experience with passenger, it does seem bloated and we decided to move away from apache to nginx for similar reasons. Tldr; We've been very happy with our move from passenger to puma.
But in our experience the app server is rarely the cause of such problems. Most people who complained about bloat in Unicorn/Puma/Passenger eventually discovered that it was a problem at the application level after all.
We'd be happy to help you with your issues if you can tell us more.
Earlier quoted context omitted.
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. What you said is basically correct. And yes, it is possible to combine event loops with threads in the way you described to get CPU concurrency as well. Whether it is actually helpful depends on the use case. The Phusion Passenger core is evented (similar to Nginx and Node.js) sin…
How does Passenger deal with blocking I/O from applications if it is single threaded? Does the entire event loop block while doing I/O?
The other component is the Ruby application process. I believe you are talking about this component.
Concurrency on the Ruby application process side is handled using two strategies:
1. Multiprocessing. 1 process per concurrent connection, with a buffering layer. This is architecturally the same as how Unicorn works when behind an Nginx reverse proxy.
2. Multithreading. 1 thread per concurrent connection, possibly with multiple processes. This is architecturally similar to Puma, though not entirely the same. It should be noted that multithreading support is available in the Enterprise version only.
I'm one of the authors behind Phusion Passenger ( https://www.phusionpassenger.com/ ), a polyglot web server for Ruby, Python and Node.js. We've recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... The comparison covers things like concurrency models, I/O models, security, clustering, multi-app support,…
Please stop making your comparisons sound as if passenger-free was a fully functional application server such as unicorn or puma. It is not. Passenger-free is a deliberately crippled demo-version. If someone wants to use passenger in production they will have to pay $50 USD per year, per server for it. And you know that very well. The 'free' passenger drops requests and serves 502 errors to the users during every sin…
The open source version of Phusion Passenger is not a crippled version. It is used in production by many large users, including New York Times, AirBnB, etc. Your statement that the open source version is "crippled" goes right against the fact that we've been actively developing the open source version ever since Enterprise came out. In fact, open source development has become more active after Enterprise than before, thanks to Enterprise funds. If you check our commits at Github you will see that the rate of development has accelerated. If you take a look at all the new features in the open source version of Phusion Passenger 4 you will see that it is improving at a tremendous rate.
It is not true that the open source Phusion Passenger drops requests and serves 502 errors to users on every single deploy. Upon touching restart.txt, the open source versions blocks requests and resumes them after having restarting 1 process. The blocking only happens for the first process, not for the ones after. At no point will requests be dropped or will errors be served. We even have integration tests in place to check for this. If you see request drops or errors in the open source version, please contact us and we'll have a better look at the problem. If it's a bug, we'll fix, it's that simple.
"popping up shareware nag-screens at random intervals" is completely false. There are absolutely no nag-screens in Phusion Passenger. The open source version of Phusion Passenger is open source, so if you don't believe me, then dig into the source code and tell me where exactly the nag screens are.
The lack of rolling restarts in the open source version is not a secret. Our documentation clearly mentions the differences between the open source and the Enterprise version. With a few clicks, you can find out what the open source version does and does not have.
And actually, the open source version does not "lack" rolling restarts, it just does not automate it for you. You can implement rolling restarts using Phusion Passenger Standalone (open source version!) in the same way you do with Thin and Mongrel, i.e. by swapping sockets. It works fine and some of our users do exactly this. It is just more work than the automated, polished, error-resistant version that Enterprise offers.
And finally, you Unicorn and Puma "fully-functional" while implying that Phusion Passenger is not. This is not true. There are features in the open source version of Phusion Passenger that Puma and Unicorn does not have. The reverse is also true. It is even true that Unicorn has some features that Puma has and vice versa.
Earlier quoted context omitted.
I think thats a little harsh. I've been using Passenger since it was called Apache mod_rails http://www.concept47.com/austin_web_developer_blog/ruby-on-r... you have to remember that before the Phusion guys showed up, there was no easy way to run a rails server without proxying requests to mongrel, thin or something like that. instances could bloat in memory or die and your app could, for whatever reason, go down and…
Yes, phusion was a viable contender for a brief timeframe. That was 5 years ago, in 2008, until unicorn came around in 2009. I don't see how their standing in 2008 excuses them to use shady trojan horse sales tactics to push their rather mediocre product in 2013.
Phusion Passenger is used to full satisfaction by many large parties, such as Motorola, UPS, Hitachi, etc. So if you can point out technical reasons why you think our product is "mediocre", please feel free to tell us, and we'll fix them.