4 ms·

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 addres

by xinuc 14y ago

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 14y ago
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 http://eepurl.com/nXXrL
- jamesbritt 14y ago
  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.
- Titanous 14y ago
  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 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 14y ago
    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.

by xinuc 14y ago

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 14y ago

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 http://eepurl.com/nXXrL

jamesbritt 14y ago
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.
Titanous 14y ago
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 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 14y ago
  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.