Phusion Passenger 4.0 beta 1 is here(blog.phusion.nl)
blog.phusion.nl
Phusion Passenger 4.0 beta 1 is here
http://blog.phusion.nl/2012/10/24/phusion-passenger-4-0-beta-1-is-here/
8 comments
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.
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.
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.
Does this mean that Passenger can now run an EventMachine service next to a Rails app?
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're looking at Node.JS, Python, Haskell, Mono(C#), PHP. Do any of these tickle your fancy or is there one missing?
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.
Python most definitely.
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 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
C# via Mono sounds very interesting :) would make deployments much easier
Haskell would be killer.
At Rackspace, we use Node.JS and Python out of those.
For playframework apps?
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.
I'm having trouble seeing the value in Phusion with nginx and python/django apps - I just use uwsgi.
Any big reasons to use it over said config?
Any big reasons to use it over said config?
See my reply here: http://news.ycombinator.com/item?id=4693943
Still no zero-downtime restarts?!
I can only wonder what the phusion guys are thinking. Either way, stick with unicorn.
I can only wonder what the phusion guys are thinking. Either way, stick with unicorn.
We have had zero-downtime restarts (or, as we call it, rolling restarts) since August 1 2012, in Phusion Passenger Enterprise: https://www.phusionpassenger.com/enterprise
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.
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 didn't ask for a marketing pitch.
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.
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.
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.
[1] https://github.com/grosser/zombie_passenger_killer
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
"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:
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 stay behind.
If you still find the spawner getting stuck in Phusion Passenger 4, then we consider this to be a bug and we would be happy to help you get to the bottom of this. I do not know what you mean by file or permission issues, but again, we would be happy to help you.
"I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger!"
There was in issue in the 2.0 series where passenger-status could corrupt internal data structures because a mutex was not being properly locked, but this has been solved later in the 2.0 series. If this was not your issue, then we would be happy to help.
"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."
The training wheels you mention predate Phusion Passenger Enterprise. Similar training wheels exist for other app servers. However the existence of these training wheels are not an indication of quality. Remember the Mongrel days and that people had to monitor them using monit? This was not because of a flaw in Mongrel itself, it was the apps and the libraries that caused crashes, memory leaks, etc. Mongrel lacked protection against these kind of things, and as a result got blamed for a lot of problems, but Mongrel was certainly not the cause of these problems.
Similarly, Phusion Passenger only offered limited protection against externally-caused problems. However with Phusion Passenger 4 and Phusion Passenger Enterprise, we are moving more and more towards supervising every single aspect of the system and making sure that things work even in the event of external problems.
We do not, and have never, claimed that our products were without flaws. However we are committed to fixing any flaws with continuing to add awesome features. And by charging money we are in a much stronger position to commit to this.
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 stay behind.
If you still find the spawner getting stuck in Phusion Passenger 4, then we consider this to be a bug and we would be happy to help you get to the bottom of this. I do not know what you mean by file or permission issues, but again, we would be happy to help you.
"I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger!"
There was in issue in the 2.0 series where passenger-status could corrupt internal data structures because a mutex was not being properly locked, but this has been solved later in the 2.0 series. If this was not your issue, then we would be happy to help.
"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."
The training wheels you mention predate Phusion Passenger Enterprise. Similar training wheels exist for other app servers. However the existence of these training wheels are not an indication of quality. Remember the Mongrel days and that people had to monitor them using monit? This was not because of a flaw in Mongrel itself, it was the apps and the libraries that caused crashes, memory leaks, etc. Mongrel lacked protection against these kind of things, and as a result got blamed for a lot of problems, but Mongrel was certainly not the cause of these problems.
Similarly, Phusion Passenger only offered limited protection against externally-caused problems. However with Phusion Passenger 4 and Phusion Passenger Enterprise, we are moving more and more towards supervising every single aspect of the system and making sure that things work even in the event of external problems.
We do not, and have never, claimed that our products were without flaws. However we are committed to fixing any flaws with continuing to add awesome features. And by charging money we are in a much stronger position to commit to this.
They have it in Passenger Enterprise.
Great work!
Node.js and python support will be nice.
Node.js and python support will be nice.
I just use uWSGI - not sure what the added value for Passenger would be.
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.
Thanks!
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 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.
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.
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'm avidly looking forward to Python and Node.js support.