Phusion Passenger 4.0 and Phusion Passenger Enterprise(blog.phusion.nl)
blog.phusion.nl
Phusion Passenger 4.0 and Phusion Passenger Enterprise
http://blog.phusion.nl/2012/07/24/roadmap-preview-1-phusion-passenger-4-0-and-phusion-passenger-enterprise/?new=1
11 comments
I think the most obvious question is, how does the new Passenger (and Enterprise) compare to the traditional setup, nginx+unicorn in terms of reliability, security and performance?
By traditional I assume you mean the setup where you have an HTTP server which reverse proxies (either doing it itself) or to HAProxy which in turn proxies to the actual Ruby application server (e.g. Mongrel, Unicorn).
In the above scenario there are just way too many parts.
Having Passenger being an all-in-one solution is pretty great.
I think most people with most apps can be very happy with Passenger.
I have been very pleased with Phusion Passenger and eagerly look forward to 4.0 and the pricing for Enterprise.
In the above scenario there are just way too many parts.
Having Passenger being an all-in-one solution is pretty great.
I think most people with most apps can be very happy with Passenger.
I have been very pleased with Phusion Passenger and eagerly look forward to 4.0 and the pricing for Enterprise.
for me, passenger is much easier to setup than unicorn etc...
the only thing i miss compared to unicorn is preload_app, which in my understanding will be addressed via the rolling restart feature.
I find it slightly amusing that nginx+unicorn is called a "traditional" setup because Phusion Passenger predates Unicorn. :)
It is true that Phusion Passenger Enterprise addresses rolling restart, but its Unicorn counterpart is not preload_app. Phusion Passenger's "smart spawning" works by first loading the app into a master process, then forking off multiple worker processes from that. Sounds familiar? That's because it's exactly the same as Unicorn's "preload_app true". Our implementation predates Unicorn.
Preloading/smart spawning in itself does not prevent app deployments from blocking clients. Rolling restarts do.
We also do rolling restarts in a different way than Unicorn does it: Unicorn works by starting a set of workers in the background, then replacing the existing ones. This means that during a rolling restart, Unicorn may require twice the memory usage. Phusion Passenger Enterprise will restart processes one-by-one and will impact memory less.
There are no _technical_ security differences between nginx+unicorn and Phusion Passenger. Both of them rely on a frontend web server to shield them from slow clients and maliciously formed requests, and neither of them run application processes as root. There are no known exploits in either tools. However Phusion Passenger makes it easy to run different apps as different users through the builtin "user switching" security feature. With Unicorn you have to do this manually by running the processes as the right user.
But when it comes to reliability, we will be announcing a feature called "deployment error resistance" in the next Roadmap Preview.
Please sign up to the Roadmap Preview mailing list, and we'll keep you up to date with the latest release progress: http://eepurl.com/nXXrL
It is true that Phusion Passenger Enterprise addresses rolling restart, but its Unicorn counterpart is not preload_app. Phusion Passenger's "smart spawning" works by first loading the app into a master process, then forking off multiple worker processes from that. Sounds familiar? That's because it's exactly the same as Unicorn's "preload_app true". Our implementation predates Unicorn.
Preloading/smart spawning in itself does not prevent app deployments from blocking clients. Rolling restarts do.
We also do rolling restarts in a different way than Unicorn does it: Unicorn works by starting a set of workers in the background, then replacing the existing ones. This means that during a rolling restart, Unicorn may require twice the memory usage. Phusion Passenger Enterprise will restart processes one-by-one and will impact memory less.
There are no _technical_ security differences between nginx+unicorn and Phusion Passenger. Both of them rely on a frontend web server to shield them from slow clients and maliciously formed requests, and neither of them run application processes as root. There are no known exploits in either tools. However Phusion Passenger makes it easy to run different apps as different users through the builtin "user switching" security feature. With Unicorn you have to do this manually by running the processes as the right user.
But when it comes to reliability, we will be announcing a feature called "deployment error resistance" in the next Roadmap Preview.
Please sign up to the Roadmap Preview mailing list, and we'll keep you up to date with the latest release progress: http://eepurl.com/nXXrL
I find it slightly amusing that nginx+unicorn is called a "traditional" setup ...
When I see "traditional" I start wondering if it means fcgi or Mongrel.
There have been quite a few traditions.
When I see "traditional" I start wondering if it means fcgi or Mongrel.
There have been quite a few traditions.
The default for Unicorn is to start a whole new set of processes, but it's pretty easy to set up a custom script that uses signals + the before/after_fork hooks to do various custom rolling restarts.
The same goes with user switching, you can just use Ruby to do it (example at the bottom of https://gist.github.com/206253).
Unicorn also already has "error resistance" in that it won't switch to a master/workers that aren't booting properly during a restart.
The same goes with user switching, you can just use Ruby to do it (example at the bottom of https://gist.github.com/206253).
Unicorn also already has "error resistance" in that it won't switch to a master/workers that aren't booting properly during a restart.
Yes, not disputing that it's possible to script things together. The appeal of Phusion Passenger has always been that you don't have to script things together: it just works.
definitelly waiting for this.
can you give us the info about the pricing scheme? how much the passenger enterprise will cost?
can you give us the info about the pricing scheme? how much the passenger enterprise will cost?
These guys deserve to make a good living from this product as its made a profound difference to the Ruby community which i think sometimes gets taken for granted.