Phusion white papers Phusion overview

Phusion Blog

The Road to Passenger 3: Technology Preview 4 – Adding new features and removing old limitations

By Hongli Lai on July 29th, 2010

In the past two years that we’ve been developing Phusion Passenger, we’ve received not only many feature requests but also many criticisms about certain limitations. Some feature requests have been implemented in Phusion Passenger 2.x, some have not. Some limitations were solved in the life time of Phusion Passenger 2, others were not because they require a lot of refactoring first. In Phusion Passenger 3 we’ve extensively refactored the code to not only make a lot of new cool features possible, but also to lift a lot of the old limitations. In this Technology Preview we are pleased to announce these changes.

Asynchronous spawning

Previously, when application processes are being spawned, Phusion Passenger is unable to handle HTTP requests until the processes are done spawning, because Phusion Passenger is holding the lock on the application pool while this is happening. Some websites have apps that need a very long time to spawn (30+ seconds) and this would be a problem for them. This behavior would also cause a “thundering herd” problem: suppose that a traffic spike appears, then the first request will cause Phusion Passenger to spawn a process. The other requests in the spike are blocked until that’s done, and then all of a sudden they are processed. Phusion Passenger thinks it needs to spawn more, so it spawns another one and blocks the rest, and so on. This can cause a large number of processes to be spawned all of a sudden, causing a long delay.

In Phusion Passenger 3 spawning happens in the background so that no clients have to be blocked. This turns out to work so well that application process spawning is now virtually unnoticeable, except when spawning the first application process.

Ability to configure minimum number of processes

Phusion Passenger automatically shuts down processes that haven’t been accessed for a while, where “a while” is configurable through the PassengerPoolIdleTime directive. Many web applications are rarely accessed during the night, so what happens is that all application processes are shut down during the night and the first person in the morning who accesses the web application has to wait for some time while the first application process is being spawned. This problem could be solved by setting PassengerPoolIdleTime to 0 or to a large number which means that processes are kept around forever or for a long time, but this also means that application processes are not shut down during the night, which might still be desirable for resource utilization reasons.

Phusion Passenger 3 introduces a new, long-awaited configuration directive: PassengerMinInstances. As its name implies, PassengerMinInstances makes sure that at least the given number of processes will be started and kept around. This, in combination with asynchronous spawning, turns out to work so well that we’ve assigned a default value of 1 for PassengerMinInstances. With Phusion Passenger 3, spawning delays should become a thing of the past!

Smart spawning support for all Rack applications

Smart spawning is a core feature of Phusion Passenger since version 1.0. It can reduce the spawning time of Rails processes by as much as 90%, and in combination with Ruby Enterprise Edition it allows you to save 33% memory on average.

However, smart spawning was limited to Rails applications only, not for Rack applications. Starting from Rails 3, all Rails 3 applications are also Rack applications, and Phusion Passenger 2 only supports smart spawning of Rails 3 applications if you remove (thereby forcing Phusion Passenger to detect it as a Rails app, not a Rack app).

Phusion Passenger 3 now supports smart spawning for all Rack applications. This works transparently and without further configuration.

Ability to access individual application processes over HTTP

When one sends a request to the web server, Phusion Passenger routes the request to one of the application processes, but one never knows up front which one that’s going to be, nor is there a way to control it. This is fine for normal requests, but sometimes one wants to send a request to a specific application process, e.g. to debug something. Another use case for accessing individual application processes directly is broadcasting messages: e.g. telling every application process to clear some local in-memory caches.

This has always been possible with reverse proxy app servers like Mongrel and Thin because each of their processes listen on their own port. Phusion Passenger 3 now also allows one to access individual application processes directly. Each application process can now be accessed through its own TCP socket port. The port numbers are randomly allocated by the operating system and the protocol is plain HTTP, so you can use existing tools like ‘curl’.

We take security very seriously. These sockets are bound to so it’s not possible to access them from remote computers. Furthermore, each socket is protected by its own unique randomly generated secure password. One can use ‘passenger-status’ to query the ports and passwords.

Global queuing now on by default

Many people with web apps that have long-running requests are familiar with the “slow Mongrel queue problem”. When one sets up Mongrel or Thin behind Nginx or Apache, it’s possible for new requests to be queued behind a Mongrel/Thin instance which is currently processing a long-running request. When other Mongrel/Thin instances become available, this new request is already queued behind the long-running request and cannot migrate to the other free instances. The more long-running requests one has the bigger of a problem this can become, resulting to very long response times for some users.

There are multiple ways to solve this problem, but Phusion Passenger has already solved this problem for a long time with a feature that we call global queuing. It was disabled by default because turning global queuing off would yield a little bit of extra performance in microbenchmarks. However for version 3.0 we’ve decided to turn it on by default: rather than saving those few milliseconds in benchmarks, we believe it’s much more important that all users get to have fair response times.

Ability to disable friendly error pages

One of the innovations that Phusion Passenger has brought us is the ability to show friendly error messages directly in the browser, e.g. when the web application fails to spawn because of a syntax error. This dramatically improves usability for developers, new and experienced alike, because one doesn’t have to manually dig into log files anymore. However this is not always desirable in production: although the error page is developer-friendly, it isn’t necessarily user-friendly. It might also expose information that the system administrator would rather not expose such as filenames.

Phusion Passenger 3 introduces a new configuration directive for controlling whether friendly error pages should be shown: ‘PassengerFriendlyErrorPages’. When turned off, Phusion Passenger will display the standard Apache/Nginx 500 Internal Server Error page instead, but all error messages are still logged to the web server error log file.

Nginx-specific improvements

In Phusion Passenger 3, Nginx is compiled with SSL support by default due to popular demand.

We’ve also introduced the following new configuration options:

passenger_set_cgi_param (name) (value)
This is the Phusion Passenger equivalent of proxy_module’s proxy_set_header. It allows you to pass arbitrary CGI environment parameters the web application.
passenger_buffer_response (on|off)
This is the Phusion Passenger equivalent of proxy_buffer. It was and still is off by default to allow streaming responses, but when streaming responses aren’t necessary one can turn this option on so that Nginx can gracefully handling clients that are slow at receiving responses.
passenger_ignore_client_abort (on|off)
This is the Phusion Passenger equivalent of proxy_ignore_client_abort.

In other news

In Technology Preview 3 we unveiled Phusion Passenger Lite. Based on various feedback that we’ve gotten since then, we’ve decided to rename this thing to Phusion Passenger Standalone in order to reduce confusion about what it is.

Towards the future

If there is one thing we’ve come to understand over time is that different businesses have different needs and constraints when it comes to deploying their applications. In order to provide the best experience and support to these businesses, we’re working on different versions of Phusion Passenger to accommodate them even better in their respective environments. In light of this, we want to underline that the technology previews we’re currently writing about will and have described the cool stuff that will be incorporated in the version intended for the most high demand environments. More information on this will follow. Having said that, almost everything we’ve blogged about up till this point will be included in the version that’s available for everybody.

  • That last paragraph smells of a “premium” version of passenger in the pipeline… :\

  • So tech preview blog posts are all good and fun, and I am looking forward to passenger 3, but where’s the code?!? 🙂

    The last commit on Github is from a month ago. Is this code out somewhere we can play with it, or do we just have to wait patiently?

  • @Ryan Sobol:
    Without confirming or denying at this point: why the “:\”? Would it be that bad of a route for us to investigate? I’m not just talking about “us” as a company, but “us” as users as well. Think about it, charging for a product if proven succesful would allow a company to invest more time in making that product even more awesome. That argument would go for both a premium version as well as a free version. In the case of Phusion Passenger, I just want to reiterate that almost everything we’ve blogged up till this point will be included in the version that is available for everybody.

    @Daniel Huckstep:
    Believe me when I say that we’re probably the most eager on getting this pushed out. I know it’s hard, but please bear with us just a little bit longer. In terms of code, I believe we’re pretty much feature complete and have been beta testing this in private for a little while as well. Having said that, we need to document a lot of the new things as well. These technology previews serve that purpose as well. In short: hang on to your seats kids, we’ve got a *lot* more coming 🙂

  • I think the concern about a premium version is that certain features will be held back from the free version to entice people to upgrade. If you’re speaking premium as more of a support contract/customization thing, I think the community will whole heartedly support that.

  • @brianthecoder:
    You wouldn’t lose anything that you wouldn’t already have when it comes to Phusion Passenger if we were to go that route. Phusion Passenger 3.x trumps Phusion Passenger 2.x in all aspects.

  • Great work guys, I am drooling in anticipation to get my hands on this one 🙂

    And for my 2 cents on the Free vs Premium thing, I think this all boils down to trust. Hundreds of companies were able to leverage the power of Passenger and I think as they grow their needs become even more complex, thus a Premium product would be great for them and if they are making money on their services using Passenger it is only so fair that they pay back as well.

    For small webapps Passenger 2 was already great and Passenger 3 Standalone would be even greater. We won’t have the Premium features but then again I think most will do just great with the Standalone version. And when they grow up their business, they will be able to contribute back by licensing the Premium version.

    So it just sounds very fair to me and I hope people understand that great technology does not come for free, out of thin air. There are many hundreds of man-hours of investment in this thing from the Phusion crew.

    Congratz, keep up with the good work!

  • Derek Hall

    I’m in favor of a premium version, and our company would pay for it assuming the features justify the cost. I’m concerned that some are discounting the premium version before even knowing the features and price.
    I have a question about the PassengerMinInstances concept: How would this differ from setting RailsAppSpawnerIdleTime to 0 ?

  • guns

    > That last paragraph smells of a “premium” version of passenger in the pipeline… :\

    What’s so wrong about that? They do excellent work, and if they want to try their hand at a premium model, I think that’s just fine. Keep in mind that the ruby webserver space is pretty crowded, so their work is cut out for them if that’s the route they go.

    Grumbling about it anyway is unbecoming.

  • How about selling a premium MIT or GPL licensed versions? Maybe sounds stupid at first, but you can legally do that, some people will buy it and won’t loose their freedom to modify / redistribute.

    RedHat does Open Source and they have also different model: their software is open source, but trademarks, logos, graphics etc. are properiaty and you can’t re-distribute them. So if people want to make fork of Passenger, it couldn’t be:
    a) named Passenger or mod_rails
    b) display error pages with the same graphics you use
    c) re-distribute the same documentation you created for premium version

    Probably one would have to think about it more in depth than what I did, and I’m not saying it’s best way forward, just an idea I have.

  • Martijn

    Looks great.. can’t wait 🙂 Great work guys.

  • I’m cool with a premium version. These guys have done an amazing job and should be rewarded for it.

  • Hold your horses folks, we’re not done announcing all the new stuff yet. A lot of TLC went into making this and it’ll take a little while longer to write about everything new.

    @Derek Hall:
    RailsAppSpawnerIdleTime will keep *all* spawned instances online indefinitely. PassengerMinInstances keeps at the very least the provided number of instances online and thus is capable of spinning down some instances as well in conjunction with PassengerMaxInstances. The difference is subtle but important to understand.

  • steved

    Don’t be apologetic about charging for the fruits for you labor.

  • Jesus

    Yes it would be bad to charge for passenger!
    I thought that the sponsoring thing that you had worked well for you. I do not know if there is a real business case here by selling passenger to a real tiny fraction of an open community. Try to go with providing service and support but keep the software free and open. If this does not work out I’m not sure if charging for a premium version will.

    On the other side I do not mind a premium version at all as long as there is a free version which runs like almost the version that is out now.

  • @Jesus: ( hehe )

    > On the other side I do not mind a premium version at all as long as there is a free version which runs like almost the version that is out now.

    The baseline in any case is that you’ll get a version which trumps Phusion Passenger 2.x in all aspects regardless of what path we choose to traverse. To strengthen that statement, I quote: “almost everything we’ve blogged about up to this point will be in the version available for everyone”. See also my earlier response to brianthecoder.

    > You wouldn’t lose anything that you wouldn’t already have when it comes to Phusion Passenger if we were to go that route. Phusion Passenger 3.x trumps Phusion Passenger 2.x in all aspects.

    In light of your reply, I don’t think you have anything to worry about. If Phusion Passenger 2.x works great for you, Phusion Passenger 3.x “version available for everyone” should work even better.

  • James

    Can Phusion confirm that Passenger will continue to be an open source project?

  • deepak

    my 2 cents is that, keep the software fully free, but charge for:
    1) training
    2) custom patches
    3) release builds earlier to paying customers ie. beta software so that that can try it out. Although i suppose the more feedback u get the better it would be.

    i personally would feel uncomfortable if it was a paid software, for something as essential as deployment. And if it becomes a freemium product , then i hope it is possible (legal) for the community to provide the missing features, and it remains open-source.

    best of luck guys.

  • @James:
    There will be a version available for everyone which will remain open source regardless of what path we choose to traverse. This version will do a better job at everything that Phusion Passenger 2.x does and more.

    So my 2 cents: why would you feel uncomfortable for paying for probably the best deployment software and ensuring it to stay the very best deployment software? I get the feeling people are already discounting the notion of a premium version while not having even waited out to see what everything will entail if we choose to go that path. We’ve provided you guys with an awesome open source deployment solution and will continue to do that. However, we are simply investigating the possibility of targeting and charging different markets. The latter if proven successful would enable us to invest much more time in developing Phusion Passenger to remain the very best deployment solution we can build. It would compensate for the pretty insane number of hours each of us needs to invest in this project, suggestions numbers 1 through 3 will only get you so far. We’re dedicated to delivering the very best deployment solution (one that innovates and exceeds everything out there by far), a process that takes a lot of time and we want to be able to do that even better. It’s as simple as that guys.

    Thanks everyone for providing their take on this. It seems however that I’m repeating myself quite a lot now in the comments and will leave it at this for now as I believe it’s something that needs a little bit more time and thought from both sides.

  • John Q

    These features look awesome, and more power to you if you can make the premium offering model work.

    I have one question on PassengerMinInstances. Is the minimum for all spawned instances, or per virtual host? In other words, if I’m hosting three apps in three separate virtual host blocks and leave PassengerMinInstances set to the default of one, will I have one instance per app or only one instance, which could be any of the three apps?

  • It’s customizable per vhost.

  • Pingback: August 3, 2010: The Most Efficient Cargo Cult Money Can Buy « Rails Test Prescriptions Blog()

  • Will the “Enterprise” donators (aka get access to the new, real “Enterprise” version? 😉

  • Ninh & Hongli, I encourage you to take the steps you need to to make Passenger a sustainable project. The community has benefitted a lot from your work. The more sustainable Passenger is for you guys, the more effort and investment you can fold back into it — and that benefits everyone.

  • Josh

    Ninh, thank you for your comments clarifying that at least some portion of Passenger is going to remain an open source project. The fact that someone was even able to pose that as a plausible question demonstrates how vague (and arguably ominous) the final paragraph was though.

    It sounds like Phusion hasn’t fully thought through what their forthcoming business model will be. Given this fact, why even say anything at all? The statements above seem to have only inspired a lot of fear and uncertainty and detracted from what was otherwise a very exciting update about the future direction of Passenger.

    Our company uses Passenger, and we have donated several times (we plan to continue doing so), but we do not want any non-OSS components to be integrated in our stack. I hope that a commitment to open source remains a core part of Phusion’s philosophy.

    Thank you for all that you have done for Ruby, for Rails, and for our company.

  • Well, if you make two versions, then using the free will always make you feel you’re using a sub-par version. Anyway, it’s good that Zed Shaw is working on Mongrel2 as with it the feeling would be: “I’m using the best thing on the planet and I don’t even have to pay for it!” Thanks, but no thanks!

  • @Josh:
    Thanks for your feedback. If the final paragraph wasn’t clear, I hope the comments have clarified it sufficiently now. As for your assumption about our business model, we have in fact thought this through quite a bit but this is all there is to say at this point.

    Anyway, not saying anything at all while disclosing the new features and springing it upon the community that there are plans to target different markets would be in poor taste. If anything, we want to assure people that even though we’re planning on segmenting on different markets, it does not necessarily mean that you’re off worse by it (quite the contrary if it’s up to us, to reiterate, almost EVERYTHING that we’ve blogged about up to this point will be included in the version available to everyone). It seems people are already drawing conclusions without having waited to see what we’re planning. As AkitaOnRails has put it, it’s about trust. Suffice it to say, open source will always remain a part of our business and the fact that there is a choice with regards to deployment solutions has encouraged us in investigating this route; if people using our high-end products feel we are delivering an inferior product with regards to the “competition”, they have the option and choice to consider alternatives. More importantly though, if it ever came to that, we would’ve failed our job and it’ll be a cold day in hell before we let it come to that ;-).

    Again, there are a lot of O/S alternatives out there that will do a good job, but the thing is, we want to do an excellent job. Seeing as there are already a lot of O/S alternatives out there, we will have our work cut out for us.

    @Nikolay Kolev:
    That might be the case, but as far as I see things “attending to everyone’s feelings” was never within our control to begin with nor one of our goals. Furthermore, this is not a zero sum game, the fact that you are entirely free in whatever you choose to feel and use is what makes diversity great. Having said that, we’re committed on delivering the very best deployment solution out there. Conversely, one might instead be feeling “I am using the very best deployment solution in the universe and have paid an X amount to ensure that it can remain that way” when using a commercial product.

    Now, as for the “I don’t even have to pay for it”, technically speaking I suppose you don’t have to pay for open source, but it never is entirely free (unless your time means nothing). I believe the same Zed Shaw you’re quoting has a nice write-up on that actually ;-). It is for this same reason why we sponsor/donate/contribute to numerous open source projects ourselves, e.g. Ruby Summer of Code etc.. and in fact Mongrel2 because we know first hand how much finances can make a change…

  • Josh

    @Ninh, thanks again for the reply and for the details. I am really excited to see what you guys are working on and I have nothing but the utmost respect for Phusion.

  • Been a fan since the very first release, when it was still modrails 😀 … can’t wait to get my hands on Passenger 3.

  • William Lee

    Well, if passenger wants to go that route, then it’s probably better to go Unicorn! instead. Only a matter of time before they go completely commercial.

  • @William Lee:
    Well, you’ve always been free to explore whatever solution you want to use of course, so if you feel Unicorn is a good fit for you, then yes, by all means, use whatever feels right for you. It’s a pretty cool solution and we’ve contributed to it as well, but we believe Passenger 3 is going to be an entirely different beast.

    Passenger has always had a very distinct philosophy of ease of use while retaining power, basically aiming to provide people with the state of the art deployment solution as we’re unveiling in these tech previews. As mentioned quite a few times over now, we’re currently exploring the segment of people who need absolutely nothing but the best and are willing to pay for that to keep it that way. It appears from your reply that you’re not part of that group and that’s perfectly fine, but please don’t go off spreading FUD e.g. “it’s just a matter of time before they go completely commercial”. You have absolutely nothing to base such a claim on and in addition, I don’t think I can be any more clear than what I’ve written before:

    “Suffice it to say, open source will always remain a part of our business and the fact that there is a choice with regards to deployment solutions has encouraged us in investigating this route; if people using our high-end products feel we are delivering an inferior product with regards to the “competition”, they have the option and choice to consider alternatives. More importantly though, if it ever came to that, we would’ve failed our job and it’ll be a cold day in hell before we let it come to that ;-)”

  • Robert

    Guys, thanks so much for all your work on Ruby Enterprise and Passenger. I’m looking forward to Passenger 3! By all means, have a premium version or whatever the heck you want to do. Make money, and keep yourselves and these awesome products around.


  • Any update on when we can play around with Passenger 3? Soon, perhaps? 🙂

  • Not much longer now. 🙂

  • Tim Clark

    Good thing we still have free alternatives like mongrel2 out there!

  • @Tim Clark:
    I’ve forwarded your comment to Zed Shaw, I’m sure he’ll appreciate it 🙂 However, comparing Passenger to mongrel2 is like comparing apples to pears. It really depends if you need apples or pears! Also, who said there won’t be a free version of Passenger anymore? If anything, I’ve tried to emphasize that there indeed actually will be. If Passenger works great for you at this time, it will continue to do so and even in a better way. I guess I should stop feeding the trolls now 😉

  • Cyrille

    Hi guys, just wondering if you are planing to releasing this week ? Actually I’ve a brand new environment to install and wanted to know if I can count on releasing on Passenger 3 🙂

    Keep the good work !

  • Rugnil

    @Ninh Bui

    Please don’t let these negative comments deter you. I think that Microsoft has sullied everyone’s view on licensing. Newsflash, everyone! Licensing fees can *actually* be reasonable!

    As long as I can run a small-to-medium sized site (non-profit sites for instance) on the free version it’s fine by me! A fair licensing price for some Enterprise features/support sounds entirely reasonable and only enables you guys to keep rocking amazing products.

    I’ve recently spent about $75,000 on server hardware for my company. I think I can manage a small licensing fee to run these servers.

  • Phillip


    I’m with you on all that you’ve said about the different markets that you are investigating. No complaints from me about any of that. Heh, no complaints at all, actually. Just one question, and if it has been answered elsewhere, kindly point me in the right direction and I’ll be on my way (I’m just now getting caught up on the Passenger 3 news):

    You said a few times that “almost everything we’ve blogged about will be in Passenger 3” that is publicly available. You seemed to stress “everything”, but my attention kept resting on “almost”. Of the things you’ve blogged about, what would be left out of the public version of Passenger 3 and be reserved for the custom environments you mentioned?


  • @Philip: Since Passenger 3 has been out for a while now you can find out for yourself. But to make it easier for you: mass deployment was the only thing that was omitted.