8 ms·

Phusion Passenger 3.0 Public Beta 1 is out

158 points by akitaonrails 16y ago

The best deployment solution for Ruby on Rails apps just got better! Test it, and see what it can do for you!

jimwise 16y ago
One tip on writing announcements like this -- always include a blurb at the start saying what your product, um, is. I've now read the full announcement. I know that there is a new version of Phusion Passenger coming out, and that a beta is available now. Problem is, when I clicked the link, I didn't know what Phusion Passenger was -- and I still don't...
- steveklabnik 16y ago
  Think "mod_rails". apache/nginx module to run Rack based applications. http://en.wikipedia.org/wiki/Phusion_Passenger http://en.wikipedia.org/wiki/Phusion_Passenger
- grandalf 16y ago
  You might want to check the following useful resource: http://lmgtfy.com/?q=phusion+passenger http://lmgtfy.com/?q=phusion+passenger
aw3c2 16y ago
If you too had no idea what this is and why people are upvoting like crazy in celebration, Wikipedia (or rather DuckDuckGo's info box!) says: Phusion Passenger is a module for the Apache HTTP Server and nginx for deployment of Ruby applications, including those built using the Ruby on Rails framework. http://en.wikipedia.org/wiki/Phusion_Passenger http://en.wikipedia.org/wiki/Phusion_Passenger
- ninh 16y ago
  Woops, sorry about that, we've included a description now at the introtext to take that into consideration. Thanks for letting us know :-)
helium 16y ago
I wonder if Mongrel2 might kill Passenger like it killed Mongrel?
- bnoordhuis 16y ago
  I doubt it. Different design goals: Passenger makes deploying Ruby web apps easy, Mongrel2 aims to be the Swiss army knife of networked servers.
- compay 16y ago
  I doubt it. But I suppose somebody could potentially build a product around Mongrel2 which does.
EvilTrout 16y ago
I never ran Phusion in production for long because of the issue with blocking when spawning, and now I see it's been fixed: http://blog.phusion.nl/2010/07/29/the-road-to-passenger-3-technology-preview-4-adding-new-features-and-removing-old-limitations/ http://blog.phusion.nl/2010/07/29/the-road-to-passenger-3-te... In fact, looking through the site, the changes that make up Phusion 3 are incredible. If it works as advertised, there should be no advantages to running Unicorn or a pack of Mongrels anymore. I can hardly wait to try it out!
- chuhnk 16y ago
  If passenger performs at the same level as or better than unicorn then its probably going to be the best implementation out there for ruby apps, especially with the choice between modules and standalone. Some of us dont actually require the "ease of deployment" as performance is the priority, phusion passenger was never about performance as they've previously stated. While the new release is faster than their previous stable, it is still yet to be seen whether it out performs unicorn. I'll reserve judgement until its been benchmarked against the other available deployment servers.
  - FooBarWidget 16y ago
    I really don't like making statements relative to other app servers. Each app server has its own merits and we believe people should decide things for themselves by running their own benchmarks and tests. However this question has been asked so many times that I'm inclined to answer in order to avoid confusion and in order to encourage people to test things independently. There exists a belief among some people that Unicorn is faster than Phusion Passenger 2. We've tested this a while ago and it turned out that they're evenly matched. Unicorn's speed is on par with Mongrel's. Unicorn's shared socket helps with fairly load balancing requests between processes but its positive effect on performance is not always significant. We've actually experimented with shared sockets and found that, when done improperly, it can actually hurt performance thanks to the thundering herd problem and the fact that catching EINTR in Ruby is expensive. All of Unicorn's I/O is handled in Ruby. A lot of Phusion Passenger's I/O is handled in C++. Instead we've opted to optimize our global queuing implementation to reach the same load balancing effect while speeding things up. Phusion Passenger 3's speed surpasses Phusion Passenger 2 by far. You draw your own conclusions. Of course you can take my answer with a grain of salt. I encourage you to verify these findings yourself.
xentronium 16y ago
Excuse my stupidity, if you can, but does passenger (+nginx) hold any advantage before nginx + single multithreaded thin instance with ruby 1.9.2?
- thibaut_barrere 16y ago
  The first one that comes to mind is that you don't have to keep the thin instance alive (eg: /etc/init.d or god scripts or SMF manifests if you're on Solaris).
- ninh 16y ago
  Ease of use, dynamic spawning of new processes and spinning them down according to the traffic you receive as opposed to a static pool of processes, fault tolerant to crashes through watchdog process which will automatically restart as much for you as it can in such an event, concurrently handling of multiple requests as opposed to a single request (thin has a multithread option but this is experimental iirc, so I'm not sure how this works yet in production). Basically less moving parts.
  - xentronium 16y ago
    Thin uses mongrel / eventmachine / rack, all non-blocking concurrent libraries. Backed up by a good ORM (I use DataMapper, but AR may have got its concurrency patches), you may roll out quite a fast application with quite a low-end server machine. So it all basically comes down to ease of deploy against more controlled environment. I think every new rails application should use 1.9.2 and rails 3 by now. Concurrency should not be an issue.
    - FooBarWidget 16y ago
      Thin doesn't use Mongrel and Mongrel isn't non-blocking and isn't a library. Rack is not a non-blocking concurrent library. You can use non-blocking concurrent libraries and use Thin in async mode yes. However the quality of support for it varies. Not everything supports Fiber-yielding-to-EventMachine at this time and for applications without long-running I/O blocking operations there's little difference in throughput between async-Thin and multiprocessing servers like Phusion Passenger. If you have long-running I/O blocking operations, like Twitter API calls that can last several seconds, then yes Thin is better. On the ease of use and stability department, we believe Phusion Passenger is easier to set up than Thin. We also monitor and restart our stuff automatically so that if anything crashes you don't have to manually restart things like is the case with Thin. As for resource consumption: Phusion Passenger can start and stop processes dynamically. On a low-end server you can configure it to not start your application process (or only start very few of them) until it's needed. We also have plans to implement multithreading support in future versions, with the eventual goal of being hybrid multiprocessed/multithreaded/evented so that the user can choose the best of all worlds.
deleted 16y ago
[deleted]
SingAlong 16y ago
what excites me is the standalone version (or perhaps "standalone mode" if that's right). It comes with an nginx core, so those who just want to launch quickly without any extra work can just do with that and then worry about scalability after gaining traction :) Thanks to Phusion
byw 16y ago
I really like the zero-downtime restart. Are there other servers beside Phusion Passenger 3 and Unicorn with this feature?

158 points by akitaonrails 16y ago

The best deployment solution for Ruby on Rails apps just got better! Test it, and see what it can do for you!

One tip on writing announcements like this -- always include a blurb at the start saying what your product, um, is. I've now read the full announcement. I know that there is a new version of Phusion Passenger coming out, and that a beta is available now. Problem is, when I clicked the link, I didn't know what Phusion Passenger was -- and I still don't...

steveklabnik 16y ago
Think "mod_rails". apache/nginx module to run Rack based applications. http://en.wikipedia.org/wiki/Phusion_Passenger http://en.wikipedia.org/wiki/Phusion_Passenger
grandalf 16y ago
You might want to check the following useful resource: http://lmgtfy.com/?q=phusion+passenger http://lmgtfy.com/?q=phusion+passenger

aw3c2 16y ago

If you too had no idea what this is and why people are upvoting like crazy in celebration, Wikipedia (or rather DuckDuckGo's info box!) says: Phusion Passenger is a module for the Apache HTTP Server and nginx for deployment of Ruby applications, including those built using the Ruby on Rails framework. http://en.wikipedia.org/wiki/Phusion_Passenger http://en.wikipedia.org/wiki/Phusion_Passenger

ninh 16y ago
Woops, sorry about that, we've included a description now at the introtext to take that into consideration. Thanks for letting us know :-)

helium 16y ago

I wonder if Mongrel2 might kill Passenger like it killed Mongrel?

bnoordhuis 16y ago
I doubt it. Different design goals: Passenger makes deploying Ruby web apps easy, Mongrel2 aims to be the Swiss army knife of networked servers.
compay 16y ago
I doubt it. But I suppose somebody could potentially build a product around Mongrel2 which does.

EvilTrout 16y ago

I never ran Phusion in production for long because of the issue with blocking when spawning, and now I see it's been fixed: http://blog.phusion.nl/2010/07/29/the-road-to-passenger-3-technology-preview-4-adding-new-features-and-removing-old-limitations/ http://blog.phusion.nl/2010/07/29/the-road-to-passenger-3-te... In fact, looking through the site, the changes that make up Phusion 3 are incredible. If it works as advertised, there should be no advantages to running Unicorn or a pack of Mongrels anymore. I can hardly wait to try it out!

chuhnk 16y ago
If passenger performs at the same level as or better than unicorn then its probably going to be the best implementation out there for ruby apps, especially with the choice between modules and standalone. Some of us dont actually require the "ease of deployment" as performance is the priority, phusion passenger was never about performance as they've previously stated. While the new release is faster than their previous stable, it is still yet to be seen whether it out performs unicorn. I'll reserve judgement until its been benchmarked against the other available deployment servers.
- FooBarWidget 16y ago
  I really don't like making statements relative to other app servers. Each app server has its own merits and we believe people should decide things for themselves by running their own benchmarks and tests. However this question has been asked so many times that I'm inclined to answer in order to avoid confusion and in order to encourage people to test things independently. There exists a belief among some people that Unicorn is faster than Phusion Passenger 2. We've tested this a while ago and it turned out that they're evenly matched. Unicorn's speed is on par with Mongrel's. Unicorn's shared socket helps with fairly load balancing requests between processes but its positive effect on performance is not always significant. We've actually experimented with shared sockets and found that, when done improperly, it can actually hurt performance thanks to the thundering herd problem and the fact that catching EINTR in Ruby is expensive. All of Unicorn's I/O is handled in Ruby. A lot of Phusion Passenger's I/O is handled in C++. Instead we've opted to optimize our global queuing implementation to reach the same load balancing effect while speeding things up. Phusion Passenger 3's speed surpasses Phusion Passenger 2 by far. You draw your own conclusions. Of course you can take my answer with a grain of salt. I encourage you to verify these findings yourself.

xentronium 16y ago

Excuse my stupidity, if you can, but does passenger (+nginx) hold any advantage before nginx + single multithreaded thin instance with ruby 1.9.2?

thibaut_barrere 16y ago
The first one that comes to mind is that you don't have to keep the thin instance alive (eg: /etc/init.d or god scripts or SMF manifests if you're on Solaris).
ninh 16y ago
Ease of use, dynamic spawning of new processes and spinning them down according to the traffic you receive as opposed to a static pool of processes, fault tolerant to crashes through watchdog process which will automatically restart as much for you as it can in such an event, concurrently handling of multiple requests as opposed to a single request (thin has a multithread option but this is experimental iirc, so I'm not sure how this works yet in production). Basically less moving parts.
- xentronium 16y ago
  Thin uses mongrel / eventmachine / rack, all non-blocking concurrent libraries. Backed up by a good ORM (I use DataMapper, but AR may have got its concurrency patches), you may roll out quite a fast application with quite a low-end server machine. So it all basically comes down to ease of deploy against more controlled environment. I think every new rails application should use 1.9.2 and rails 3 by now. Concurrency should not be an issue.
  - FooBarWidget 16y ago
    Thin doesn't use Mongrel and Mongrel isn't non-blocking and isn't a library. Rack is not a non-blocking concurrent library. You can use non-blocking concurrent libraries and use Thin in async mode yes. However the quality of support for it varies. Not everything supports Fiber-yielding-to-EventMachine at this time and for applications without long-running I/O blocking operations there's little difference in throughput between async-Thin and multiprocessing servers like Phusion Passenger. If you have long-running I/O blocking operations, like Twitter API calls that can last several seconds, then yes Thin is better. On the ease of use and stability department, we believe Phusion Passenger is easier to set up than Thin. We also monitor and restart our stuff automatically so that if anything crashes you don't have to manually restart things like is the case with Thin. As for resource consumption: Phusion Passenger can start and stop processes dynamically. On a low-end server you can configure it to not start your application process (or only start very few of them) until it's needed. We also have plans to implement multithreading support in future versions, with the eventual goal of being hybrid multiprocessed/multithreaded/evented so that the user can choose the best of all worlds.

deleted 16y ago

[deleted]

SingAlong 16y ago

what excites me is the standalone version (or perhaps "standalone mode" if that's right). It comes with an nginx core, so those who just want to launch quickly without any extra work can just do with that and then worry about scalability after gaining traction :) Thanks to Phusion

byw 16y ago

I really like the zero-downtime restart. Are there other servers beside Phusion Passenger 3 and Unicorn with this feature?