Phusion white papers Phusion overview

Phusion Blog

Phusion Passenger community sponsorship campaign

By Hongli Lai on February 16th, 2009

We are happy to see that more and more people are using Phusion Passenger for deploying their favorite Ruby web applications. Although Phusion Passenger is very much usable at its current state, it is under constant development and is constantly being improved. Those who have been following the development in our git repository are probably aware of the exciting improvements that the next Phusion Passenger release – version 2.1 beta – will bring. Here’s a summary:

Improved compatibility with other Apache modules, such as mod_rewrite
Phusion Passenger is now fully compatible with mod_rewrite! The “RailsAllowModRewrite” option is now obsolete, and everything should work as expected.

While this might sound like a trivial improvement, please think about this for a moment, because supporting mod_rewrite has been anything but trivial. The way mod_rewrite interacts with Apache is for the most part undocumented. We have spent many, many, many man hours on reading mod_rewrite’s source code, Apache’s source code and many Apache modules’ source code, and reverse engineering its behavior through debuggers, in order to figure out how to make Phusion Passenger fully compatible. To get an idea of how much effort we spent into this, take a look at the Phusion Passenger Apache module source code. Even if you’re not familiar with C++, you might be interested in the comments associated with the following functions: prepareRequest, saveOriginalFilename, saveStateBeforeRewriteRules, undoRedirectionToDispatchCgi, startBlockingModDir, startBlockingModAutoIndex.
The information in all these comments are obtained through hard reverse engineering work, because the behavior that these comments describe are not documented anywhere. We had to obtain this information the hard way.

Ruby 1.9 support
As announced here.
Support for NFS setups
Using Phusion Passenger to deploy applications that live on NFS shares is currently a bit awkward, and performance isn’t that good either because of filesystem access overhead. We’ve made Phusion Passenger more NFS friendly! Performance on NFS shares has been increased by up to 8 times thanks to smart filesystem access caching. Restarting applications that live on NFS shares now works seamlessly.
Various I/O handling and scaling improvements and fixes
Phusion Passenger will now try much harder to enforce I/O timeouts, so that a bad, slow or frozen HTTP client cannot hog server resources forever.

We’ve improved mod_xsendfile support. If a backend process sends an X-Sendfile response, then Phusion Passenger used to keep that backend process locked until mod_xsendfile has sent the file. This has been solved: Phusion Passenger will now immediately release the backend process, making things much more scalable.

Phusion Passenger now fully supports applications that stream large amounts of data. Apache has the tendency to buffer the entire response in memory before sending it to the HTTP client. We’ve suppressed this Apache behavior, so now your Ruby web application can happily stream hundreds of megabytes of data, and things will keep working smoothly.

Ability to disable Phusion Passenger for arbitrary URLs (PassengerEnabled option)
This allows you to, for example, integrate PHP applications alongside Ruby/Rails applications on the same virtual host.

Improved application compatibility
If your application has a model named ‘Passenger’ then it will not work on Phusion Passenger 2.0.x because that’s how our namespace is called. We’ve renamed our namespace to ‘PhusionPassenger’, so this problem is now a thing of the past.

Some applications are incompatible with Phusion Passenger’s smart spawning mode, and have to be deployed in conservative spawning mode. As you might know, smart spawning can reduce a Rails application’s startup time by as much as 90% in the right circumstances, as well as decreasing its memory usage, so it’s no surprise that smart spawning is preferred over conservative spawning. We’ve added various hooks which allows developers of incompatible applications to make their applications compatible with smart spawning.

Phusion Passenger depends on the ‘rack’ gem in order to support Rack applications. The latest ‘rack’ gem is version 0.9.1, but some applications have (incorrectly) specified a hard dependency on rack 0.4.0. If both 0.9 and 0.4 are installed, then these applications will break when run in Phusion Passenger, because the application tries to load 0.4 after 0.9 has already been loaded. We’ve implemented a fix so that even these applications will now work correctly.

Better cross-platform support
MacOS X support as well as support for 64-bit platforms have been much improved. Sun Solaris is now officially supported, thanks to contributions by Alex Osborne, Jacob Harris, alex.kiernan, Alex Tomlins and J Aaron Farr.
Non-interactive installer
The installer can now be run in non-interactive mode, ideal for scripting. Use the –auto command line option.
Improved command-line admin tools
For example, the ‘passenger-status’ tool now displays additional useful information such as a worker process’s uptime and how many requests it has processed so far.
Ability to display backtraces for all threads
If you’re using the latest version of Ruby Enterprise Edition, or if you’re using a Ruby interpreter with the caller_for_all_threads patch, then Phusion Passenger gives you the ability do dump the backtraces of all running threads to a log file. This makes it much easier to debug multithreaded web applications.
Improved security
We’ve taken various precautions in order to improve overall security. For example, if user switching is disabled, then all Phusion Passenger helper daemons will be run as non-root (they must be root for user switching to work). Temp directory permissions have been tightened to prevent malicious tampering.
More customization options for exotic systems/setups
It is now possible to customize the ‘tmp’ directory that Phusion Passenger uses. This is especially useful on systems on which Apache can’t write to /tmp (e.g. on many systems with SELinux), or systems on which /tmp is not a good candidate for temporary files for whatever reason. It’s now also possible to customize the directory in which Phusion Passenger looks for ‘restart.txt’. Global queuing usage can now be customized per-virtual host. It’s now possible to explicitly specify the location of the web application’s root directory, in case DocumentRoot + “/..” is not the correct directory.
Various usability improvements
In particular, many error messages have been improved so that end users don’t have to stare at the screen for minutes wondering what the computer is trying to tell them. There are also many small usability improvements here and there.
Various other minor improvements and bug fixes
PassengerPoolIdleTime can now be set to 0, which means that the backend application must never idle timeout. This feature has been contributed by redmar.
The passenger-status tool will now display Phusion Passenger’s own backtraces for C++ code, in order to make it possible to detect potential freezes in C++ code.
Phusion Passenger error pages now return HTTP 500 errors, as they should.
The ApplicationSpawner server and FrameworkSpawner server idle times can now be customized.
In the 2.0.x series, sometimes more backend processes might be spawned than is allowed by the ‘PassengerMaxPoolSize’ option. This has been fixed.

Announcing the first Phusion Passenger community sponsorship campaign

Phusion Passenger is open source and 100% free (as in gratis), so before we release 2.1, we’d like to call upon the community to support Phusion Passenger’s development by sponsoring us. This campaign is public, so anybody can join.

There’s one crucial thing missing from the above list of improvements: documentation. Most of the improvements are currently undocumented. By sponsoring us, you’ll also ensure that the 2.1 release will come with high-quality and up-to-date documentation. We’ve already started working on the documentation, but there’s a lot that remains to be done.

The goal of this campaign is $14000. We already have one sponsor,, who has donated $2000, so only $12000 remains.

Once the campaign goal has been reached, we’ll release 2.1 as soon as possible. Highlights:

  • All sponsors will be given credit on the related Phusion Passenger release announcement on our blog. If the sponsor is an organization then we’ll link to the website, if available.
  • The money that we receive through this campaign shall be treated like donations.
  • An invoice is available if both of the following conditions apply:
    • You are an organization based in the European Union.
    • You’ve sent 300 USD or more.

To sponsor this campaign, please click on the following button:
Click here to lend your support to: Phusion Passenger first community sponsorship and make a donation at !

NOTE: Some people might see the Paypal page in Dutch. We do not yet know why this happens and we’re currently investigating it. But if you’re wondering what to choose in the country drop-down box: “United States” is “Verenigde Staten” in Dutch.

This has now been fixed.