We are continuously improving Phusion Passenger, and we strive to be the best application server out there when it comes to stability, reliability, performance and ease of use. Not just for Ruby. If you have any feedback on how we can improve, please let us know.
Please extend the Passenger Enterprise $99/year "Startup" license to include "hackers" as well as "startups, students, educational use, and non-profits".
I have a handful of pet Ruby projects in the pipeline which won't make money, and I'd like to run them on a VPS using the Passenger Enterprise mass deployment feature with rolling restarts. At $249/year, I'm not too keen. But at $99/year I'd go for it.
If you don't make money, doesn't that make you a non-profit? If you do make money, then you're either a startup or an established business. I don't know what a "hacker" is in your context? Why does a "hacker" need mass deployment and rolling restarts, while the feature is not worth 249 for him?
I am not a registered non-profit. I am a developer with a day job who'd like to host my side-projects on an inexpensive VPS using Passenger Enterprise.
As things stand, Ruby hackers can either host their pet projects on Heroku or come up with a DIY solution to manage virtual hosts and graceful restarts on a VPS.
In my opinion, the convenience of mass deployment and rolling restarts is worth $99 for projects that do not make money, but it becomes a questionable annual expense at $249. From the upvotes on my initial comment, I think that others in my position may feel the same. And it seems like a good way to encourage people who build things for fun to look to Passenger Enterprise for their bigger, paid projects too.
Since our goal for Phusion Passenger is for it to become the ultimate polyglot webserver, which technology would you guys want to see support for the most?
We're looking at Node.JS, Python, Haskell, Mono(C#), PHP. Do any of these tickle your fancy or is there one missing?
We posted our passenger+python announcements on the Python reddit before, but we didn't get much attention for it. Do you know in what way we could really address the Python webdevelopment community?
post benchmarks cause the python community love those, and make it work nicely with gevent. Just make a little hello world Flask app and show us how it performs.
I use Passenger for my Ruby projects, but use nginx with gunicorn for Python - no reason behind that choice whatsoever except that is the stack that I found nice blog articles on how to get working with gevent
I've been using passenger's wsgi support for close to two years. (I transitioned from ruby to python for web dev so it's no surprise that I stayed with what I knew best). I would love to see Mono support as it is in desperate need of a good webserver - especially now since the ASP.NET stack was open sourced.
uWSGI requires another daemon which you must manage. With uWSGI, you must configure Nginx to forward requests to that daemon. Phusion Passenger fully integrates into Nginx so that is no longer necessary. With less moving parts, there is less system administration overhead.
The uWSGI project solved that "issue" (really, i have difficults calling it an issue, but i can understand the point of passenger guys) with the "uWSGI Emperor" more than one year ago in a pretty elegant (and system-friendly) way. You may want to look at it.
Yup! I already use it - I have templated config files so I just create a symbolic link when creating a new Django app.
I didn't have to configure Emperor mode on my new Ubuntu machine - it has a directory where configs are stored. I remember 8 or 10 months ago, you had to configure emperor mode and set the "vassals" directory, not anymore I guess.
We also implement rolling restarts more conveniently than Unicorn:
* There are multiple ways to implement rolling restarts in Unicorn. One of them is by sending SIGUSR2. This makes Unicorn fork off a new master with the same number of workers. However this requires twice the memory usage during a restart.
* There are ways to script Unicorn to make it restart process-by-process, but this requires some effort.
* Phusion Passenger Enterprise implements rolling restarts with a single config option (PassengerRollingRestarts on), and it performs process-by-process restarting so that you don't need twice the memory usage. It automates everything for you.
* The "deployment error resistance" feature, which can be used in combination with rolling restarting, ensures that in case your new app version doesn't start, it keeps the old processes around until an administrator manually tells it to restart again.
There are many other features in Phusion Passenger Enterprise which Unicorn does not implement (e.g. live IRB console), or that we implement better. Take a look, you may like it.
We are flattered that you like Unicorn. Being Unicorn contributors ourselves, it's always good to see people contend with technology that we've contributed to. :) Phusion Passenger 4 is the combination of all the experience that we've built up in the past few years, in both Phusion Passenger and Unicorn.
I just wanted to point out that your free product lacks a critical, basic feature. Many passenger-users don't seem to be aware that they are serving HTTP 502/503 error pages to their users during every deploy unless they pay $10 per server and month for your convenience.
If price is your biggest concern, then by all means, continue using free products. We charge money because the money - and having a sustainable business - allows us to develop the very best product and allows us to provide excellent support.
It is not a secret which features are and aren't available in Enterprise. The documentation and the website are very clear on this.
The documentation and the website are very clear on this.
For the longest time (until 2 months ago) your documentation and website were not clear about it at all. It was simply not mentioned because passenger didn't support it.
Since you take every opportunity here to inject your marketing hyperbole I'll provide my counterweight: In my experience passenger is far from the "very best" in any regard. Admittedly the last version I have used was 3.0.11.
The build-system used to be a trainwreck, plain and simple. At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product). These were usually related to the Spawner getting stuck or file/permission issues. I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger! (I did not set that one up and never figured out the root-cause, we just migrated it to unicorn).
In general, when people sit down and write training-wheels[1] for your product, then you might want to strike a tad more humble tone in a hacker-forum.
"For the longest time (until 2 months ago) your documentation and website were not clear about it at all. It was simply not mentioned because passenger didn't support it."
That's because Phusion Passenger Enterprise and the rolling restart feature were only released 2 months ago. You can't exactly document something that doesn't exist yet, can you? However we've already mentioned as early as last year on the mailing list that there will be a commercial version and that rolling restarts will only be available in there.
"The build-system used to be a trainwreck, plain and simple."
I do not know what you mean by trainwreck here. Our build system is a simple Rakefile with building rules that invoke the compiler, plus an installer script that invokes Rake. Our build system goes through great pains to autodetect as many things as possible, to avoid burdening the user. It even goes as far as detecting bugs in the system and working around them. You can read some of the source code here:
As far as I know we are the only piece of software in our category trying so hard. But if you are having problems with compilation, we would be happy to help you.
"At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product)."
Alright, here are the facts. Errors are always logged to the web server error log. There are a limited number of known cases in which that does not happen, or does not seem to happen:
1. The user is looking in the wrong file. As strange as this might seem, it actually happens. A classical example involves declaring the Nginx 'error_log' directive inside the 'http' block. This makes Nginx open a log file, and all the Nginx error logging functions write to that file, but it does not redirect stderr to that log file. Since Phusion Passenger usually writes error messages to stderr, the error message does not appear in that file, and the user is confused. The solution is to move the 'error_log' directive outside the 'http' block and into the global context.
2. Sometimes the error is written to stdout. Thanks to weird environment issues on some systems (some OS X versions, I'm looking at you), stdout is sometimes redirected to /dev/null so you don't see the error at all.
In Phusion Passenger 4 we've taken more extreme measures to ensure that errors always get logged. For example we forcefully redirect stdout to stderr. If all else fails, we provide a config option with which you can tell Phusion Passenger to redirect its stdout and stderr to a file.
If you still encounter cases in which no error is shown, then we consider this a bug and we could be happy to work with you to solve this problem.
"These were usually related to the Spawner getting stuck or file/permission issues."
So here are the facts again.
Phusion Passenger 3 and earlier assume that the app behaves correctly during startup and shutdown. That's why it did not enforce any timeouts on these operations. We have documented this extensively in our blog post "The right way to deal with frozen processes on Unix": http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-with...
However, starting from Phusion Passenger 4, we've much improved in this area. Application processes now have a 1 minute limit to start. Otherwise, they are killed with SIGKILL. Similarly, when you shut down the web server, the Watchdog now kills all application processes with SIGKILL after a short timeout, to ensure that no garbage processes st...
The ability to run multiple rubies is a very welcome addition, and just in time now that Rails 4 drops support for Ruby 1.8. It's going to save us alot of hassle transitioning legacy apps over. Thanks alot.
31 comments
[ 792 ms ] story [ 6776 ms ] threadI have a handful of pet Ruby projects in the pipeline which won't make money, and I'd like to run them on a VPS using the Passenger Enterprise mass deployment feature with rolling restarts. At $249/year, I'm not too keen. But at $99/year I'd go for it.
As things stand, Ruby hackers can either host their pet projects on Heroku or come up with a DIY solution to manage virtual hosts and graceful restarts on a VPS.
In my opinion, the convenience of mass deployment and rolling restarts is worth $99 for projects that do not make money, but it becomes a questionable annual expense at $249. From the upvotes on my initial comment, I think that others in my position may feel the same. And it seems like a good way to encourage people who build things for fun to look to Passenger Enterprise for their bigger, paid projects too.
We're looking at Node.JS, Python, Haskell, Mono(C#), PHP. Do any of these tickle your fancy or is there one missing?
I use Passenger for my Ruby projects, but use nginx with gunicorn for Python - no reason behind that choice whatsoever except that is the stack that I found nice blog articles on how to get working with gevent
Node.js and python support will be nice.
I didn't find it too difficult to setup uWSGI, but I can see how it can suck if you have too many apps, or apps of different types.
I didn't have to configure Emperor mode on my new Ubuntu machine - it has a directory where configs are stored. I remember 8 or 10 months ago, you had to configure emperor mode and set the "vassals" directory, not anymore I guess.
I can only wonder what the phusion guys are thinking. Either way, stick with unicorn.
We also implement rolling restarts more conveniently than Unicorn:
* There are multiple ways to implement rolling restarts in Unicorn. One of them is by sending SIGUSR2. This makes Unicorn fork off a new master with the same number of workers. However this requires twice the memory usage during a restart.
* There are ways to script Unicorn to make it restart process-by-process, but this requires some effort.
* Phusion Passenger Enterprise implements rolling restarts with a single config option (PassengerRollingRestarts on), and it performs process-by-process restarting so that you don't need twice the memory usage. It automates everything for you.
* The "deployment error resistance" feature, which can be used in combination with rolling restarting, ensures that in case your new app version doesn't start, it keeps the old processes around until an administrator manually tells it to restart again.
There are many other features in Phusion Passenger Enterprise which Unicorn does not implement (e.g. live IRB console), or that we implement better. Take a look, you may like it.
We are flattered that you like Unicorn. Being Unicorn contributors ourselves, it's always good to see people contend with technology that we've contributed to. :) Phusion Passenger 4 is the combination of all the experience that we've built up in the past few years, in both Phusion Passenger and Unicorn.
I just wanted to point out that your free product lacks a critical, basic feature. Many passenger-users don't seem to be aware that they are serving HTTP 502/503 error pages to their users during every deploy unless they pay $10 per server and month for your convenience.
It is not a secret which features are and aren't available in Enterprise. The documentation and the website are very clear on this.
For the longest time (until 2 months ago) your documentation and website were not clear about it at all. It was simply not mentioned because passenger didn't support it.
Since you take every opportunity here to inject your marketing hyperbole I'll provide my counterweight: In my experience passenger is far from the "very best" in any regard. Admittedly the last version I have used was 3.0.11.
The build-system used to be a trainwreck, plain and simple. At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product). These were usually related to the Spawner getting stuck or file/permission issues. I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger! (I did not set that one up and never figured out the root-cause, we just migrated it to unicorn).
In general, when people sit down and write training-wheels[1] for your product, then you might want to strike a tad more humble tone in a hacker-forum.
[1] https://github.com/grosser/zombie_passenger_killer
That's because Phusion Passenger Enterprise and the rolling restart feature were only released 2 months ago. You can't exactly document something that doesn't exist yet, can you? However we've already mentioned as early as last year on the mailing list that there will be a commercial version and that rolling restarts will only be available in there.
"The build-system used to be a trainwreck, plain and simple."
I do not know what you mean by trainwreck here. Our build system is a simple Rakefile with building rules that invoke the compiler, plus an installer script that invokes Rake. Our build system goes through great pains to autodetect as many things as possible, to avoid burdening the user. It even goes as far as detecting bugs in the system and working around them. You can read some of the source code here:
https://github.com/FooBarWidget/passenger/blob/master/lib/ph...
https://github.com/FooBarWidget/passenger/tree/master/lib/ph...
As far as I know we are the only piece of software in our category trying so hard. But if you are having problems with compilation, we would be happy to help you.
"At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product)."
Alright, here are the facts. Errors are always logged to the web server error log. There are a limited number of known cases in which that does not happen, or does not seem to happen:
1. The user is looking in the wrong file. As strange as this might seem, it actually happens. A classical example involves declaring the Nginx 'error_log' directive inside the 'http' block. This makes Nginx open a log file, and all the Nginx error logging functions write to that file, but it does not redirect stderr to that log file. Since Phusion Passenger usually writes error messages to stderr, the error message does not appear in that file, and the user is confused. The solution is to move the 'error_log' directive outside the 'http' block and into the global context.
2. Sometimes the error is written to stdout. Thanks to weird environment issues on some systems (some OS X versions, I'm looking at you), stdout is sometimes redirected to /dev/null so you don't see the error at all.
In Phusion Passenger 4 we've taken more extreme measures to ensure that errors always get logged. For example we forcefully redirect stdout to stderr. If all else fails, we provide a config option with which you can tell Phusion Passenger to redirect its stdout and stderr to a file.
If you still encounter cases in which no error is shown, then we consider this a bug and we could be happy to work with you to solve this problem.
"These were usually related to the Spawner getting stuck or file/permission issues."
So here are the facts again.
Phusion Passenger 3 and earlier assume that the app behaves correctly during startup and shutdown. That's why it did not enforce any timeouts on these operations. We have documented this extensively in our blog post "The right way to deal with frozen processes on Unix": http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-with...
However, starting from Phusion Passenger 4, we've much improved in this area. Application processes now have a 1 minute limit to start. Otherwise, they are killed with SIGKILL. Similarly, when you shut down the web server, the Watchdog now kills all application processes with SIGKILL after a short timeout, to ensure that no garbage processes st...
Any big reasons to use it over said config?