

Phusion Passenger 4.0 and Phusion Passenger Enterprise - FooBarWidget
http://blog.phusion.nl/2012/07/24/roadmap-preview-1-phusion-passenger-4-0-and-phusion-passenger-enterprise/?new=1

======
floydprice
Can't wait to see what features the new Paid (Enterprise) version will have
over the Open Source (Community) version...

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.

------
tzaman
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?

~~~
xinuc
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.

~~~
FooBarWidget
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>

~~~
Titanous
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.

~~~
FooBarWidget
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.

------
xinuc
definitelly waiting for this.

can you give us the info about the pricing scheme? how much the passenger
enterprise will cost?

~~~
tinco
We'll be announcing the pricing very soon, just making the last finishing
touches on the launch website :)

We'd also love to know what other features you want to see in Passenger :)

~~~
xinuc
rolling restart is the killer for me... this is the only feature i miss from
passenger compared with unicorn.

