Ruby on Rails Planet

A sneak preview of Phusion Passenger 3.2, part 2 »

Created at: 26.04.2012 00:23, source: Phusion Corporate Blog, tagged: Phusion Passenger

In our last Phusion Passenger sneak preview article we described a number of large but exciting changes in the upcoming 3.2 series. Since then, much development progress has been made thanks to much-appreciated user feedback. A ton of bugs have been fixed and we’re almost ready to dogfood it (running it in production on our own servers). We’re already using the 3.2 pre-release code on our development workstations while developing web apps.

In this article I shall explain more changes that the 3.2 series brings.

More zero-copy I/O

In the Phusion Passenger 3.0 technology preview articles we first described the introduction of a zero-copy I/O architecture. In 3.2, this architecture has evolved a lot further. In most performance-critical places we now avoid copying data whenever we can, and we use scatter-gather I/O calls all over the place instead of traditional I/O calls.

What is scatter-gather I/O? Normally when you have strings from multiple memory addresses, and you want to write them over a file descriptor, you have two choices:

Concatenate all strings into one big string, and send the big string to the kernel. This requires more memory and involves copying data, but only involves one call to the kernel. A kernel call tends to be much more expensive than a concatenation operation unless you’re working with a lot of data.
Send each string individually to the kernel. You don’t need as much memory but you need a lot of expensive kernel calls.

Normal I/O

In a similar fashion, if you want to read some data from a file descriptor but you want different parts of the data to end up in different memory buffers, then you either have to read() the data into a big buffer and copy each parts to the individual buffers, or you have to read() each part individually into its own buffer.

With scatter-gather I/O you can pass an array of memory buffers to the kernel. This way you can tell the kernel to write multiple buffers to a file descriptor, as if they form a single contiguous buffer, but with only one kernel call. Similarly you can tell the kernel to put different parts of the read data into different buffers. On Unix systems this is done through the readv and writev() system calls. In Phusion Passenger 3.2 we use the latter system call extensively.

Unfortunately writev() has many quirks. Typical implementations cannot handle more than IOVEC_MAX buffers per call where IOVEC_MAX is a constant with an arbitrary number. On some implementations the call will fail if the limit is surpassed, but on Linux/glibc it will quietly concatenate everything into a big buffer for you! Neither are desirable properties in Phusion Passenger, but we at Phusion care about stability so we have written extensive code to take care of this issue.

Environment variable passing

Properly passing environment variables in Phusion Passenger 3 for Apache is quite a pain. People expect SetEnv to just work, but in practice it doesn’t because of various implementation details in Phusion Passenger. To pass things like LD_LIBRARY_PATH you had to write a wrapper script. Passing PATH works but only if you’re not expecting it to affect the search path for the Ruby interpreter itself.

In 3.2 we fully support passing environment variables with SetEnv, and it works as expected. This is actually a side effect of supporting multiple Ruby versions, but it works out rather nicely.

Less memory usage

Phusion Passenger has always been lightweight when it comes to memory usage, but in 3.2 we’ve reduced it even further. More parts have been moved from Ruby into C++. The Ruby component now only load code that’s absolutely necessary. The result is massive memory savings:

When using the smart spawn method, the Preloader process (formerly called the ApplicationSpawner process) now uses 300 KB less memory.
When using the direct spawn method (the new name for the conservative spawn method), the request handler now uses 500 KB less memory per application worker process.
The Ruby stack, as is reachable at the Rack application object’s starting point, has been reduced from about 10 levels to only 2 levels. This results in at least 8 KB of reduced stack size. If your application is multithreaded and you’re still on Ruby 1.8 then you should see faster thread context switching performance.

Memory measurements are done on OS X Lion. Your mileage may vary.

Release date

So people have been asking us when 3.2 will be released. We want to make sure that the 3.2 release is a rock-solid one, as we always do with our products. But we need your help. Please download the 3.2 pre-release code from Github and play with it and report any bugs you find. Or better yet: send us a patch. It’s getting more and more stable by the day but you can make the process even faster.

New Phusion Passenger documentation pages »

Created at: 15.04.2012 14:58, source: Phusion Corporate Blog, tagged: Phusion Passenger

The Phusion Passenger documentation is written with the excellent Asciidoc tool, which Git also uses for its manual pages. The output looks good but it’s nothing too fancy. There were a few features that we’ve wanted for a while but aren’t available in Asciidoc. We’ve written a wrapper tool around Asciidoc called Mizuho, which provides these features.

Today, we present you with the new Phusion Passenger documentation pages.

Top bar with useful shortcuts

enter image description here

The new documentation has a top bar which gives you quick access to the table of contents. It also tells you where in the documentation you are. Scroll down in the documentation, you’ll see the top bar’s title updating itself accordingly.

Per-section comments

enter image description here

You can now comment on a section by clicking on the bubble on the left of a section title. Comments are powered by Juvia.

The documentation

A sneak preview of Phusion Passenger 3.2 »

Created at: 13.04.2012 18:59, source: Phusion Corporate Blog, tagged: Phusion Passenger

We’ve been working on Phusion Passenger 3.2 on local repositories for a while now. Today we just pushed this code to Github. You can find it in the experimental branch. Despite the relatively minor version bump, Phusion Passenger 3.2 has actually received a major internal overhaul. This is because our version number growth rate is based on the quantity of user-visible improvements, not internal (technical) improvements.

Rewritten ApplicationPool

One of the central subsystems in Phusion Passenger is the ApplicationPool, which spawns Ruby application processes when necessary and keeps track of them. It scales the number of processes according to the current traffic and it ensures that the number of processes do not go over your defined resource limits. It’s one of the most complex parts of Phusion Passenger and consists of a lot of carefully written code. The ApplicationPool also goes through a huge amount of effort to ensuring that the user is appropriately notified in the event of problems. One of the nerving things about FastCGI (what a lot of people used before Mongrel and Phusion Passenger were introduced) was that when something goes wrong, you often have absolutely no idea why. There is no error report. Or sometimes it prints an error report to a log file, but users often have no idea where that log file is or even realize that they have to look in the log file in the first place. In contrast, Phusion Passenger displays this beautiful error message page which tells you all the details of the problem, right there in the browser. And because Phusion Passenger is heavily multithreaded, ApplicationPool was designed to be thread-safe. However, our initial implementation (during the 1.x and 2.x days) was not concurrent enough: the ApplicationPool’s mutex was locked while an application process is being spawned. This meant that Phusion Passenger is essentially frozen whenever an application process is being spawned; it will be unable to serve any requests during this time. You can’t even run passenger-status while this is happening. Phusion Passenger 3.x partially solves this issue by spawning all processes in the background, except for the first one. Another problem is that if an application behaves badly and freezes during startup, then Phusion Passenger also stays frozen. The ApplicationPool subsystem in 3.0 is partially written in C++, partially in Ruby. However we’ve found that Ruby is not a good language for system software such as Phusion Passenger. Although we love Ruby and still think Ruby is great for lots of things (web apps, sysadmin software, etc) we realized that it’s better to move that part to C++ instead. And we did: in Phusion Passenger 3.2, we’ve rewritten the entire ApplicationPool subsystem in C++. The new subsystem is much more concurrent and more fault-tolerant. It no longer holds the lock for an extended period of time and never freezes, ever. It enforces a spawn timeout on all processes: if they fail to spawn within 60 seconds then they will be killed. The new code is also much easier to understand and to maintain. This opens the road towards many potential future enhancements. 3.2 also supports multiple Ruby versions at the same time, something which many people have been waiting for.

Request/response I/O handling is now evented

Phusion Passenger <= 3.0 uses a static number of threads to handle request/response I/O. This severely limits the amount of concurrent I/O that we can handle. in 3.2, our request/response I/O handling subsystem has been rewritten to be single-threaded and evented. We use the excellent libev and libeio libraries by Marc Lehmann. This evented I/O subsystem allows us to handle a virtually unlimited amount of I/O requests concurrently and also solves some pathological edge case I/O problems that Phusion Passenger currently suffers from. It also opens the road towards future support for WebSockets, long polling and other mechanisms which require a connection socket to stay open for a potentially long time. One of the best features in the new I/O handler is real-time disk-buffered response forwarding. Traditionally, the web server would buffer the entire response before sending it to the client. This is necessary because you don’t want slow HTTP clients to block the application. However it also means that it’s not possible to flush partial response data to the client immediately (e.g. Rails 3.2 streaming), at least not without risking slow clients blocking the application. In Phusion Passenger 3.2, if the client is slow then we buffer the response data in memory, or to disk if the data is larger than a certain threshold. In contrast to most web servers we do not wait until the entire response has finished before forwarding the data; we do it immediately! You don’t need to turn this on, it’s enabled by default. Now application developers need never worry about response buffering anymore, it Just Works(tm) and does the right thing.

Improved WSGI support

It’s not a well-known fact because we’ve never made a fuss about it, but Phusion Passenger actually supports Python WSGI as well, and has done this since the 1.x days. Here’s a demonstration of Django running on Phusion Passenger and a demonstration of Pylons running on Phusion Passenger. Our WSGI support worked, but wasn’t particularly good. For example if the application fails to spawn then we do not display an error message in the browser. But we do now, so WSGI is now unofficially supported as a first-class citizen. Python processes are managed just like Ruby processes; all the resource limits, response buffering, etc. work exactly in the same way.

Phusion Passenger 3.0.12 released »

Created at: 13.04.2012 11:42, source: Phusion Corporate Blog, tagged: Phusion Passenger

Phusion Passenger is an Apache and Nginx module for deploying Ruby web applications. It has a strong focus on ease of use, stability and performance. Phusion Passenger is built on top of tried-and-true, battle-hardened Unix technologies, yet at the same time introduces innovations not found in most traditional Unix servers. Since version 3.0 it can also run standalone without an external web server, making it not only easier for first-time users but also ideal on development environments.

Recent changes

Phusion Passenger is under constant maintenance and development. We are pleased to announce Phusion Passenger version 3.0.12. This is a bug fix release.

[Apache] Support Apache 2.4. The event MPM is now also supported.
[Nginx] Preferred Nginx version upgraded to 1.0.15.
[Nginx] Preferred PCRE version upgraded to 8.30.
[Nginx] Fixed compatibility with Nginx < 1.0.10.
[Nginx] Nginx is now installed with http_gzip_static_module by default.
[Nginx] Fixed a memory disclosure security problem.: The issue is documented at http://www.nginx.org/en/security_advisories.html and affects more modules than just Phusion Passenger. Users are advised to upgrade as soon as possible. Patch submitted by Gregory Potamianos.
[Nginx] passenger_show_version_in_header now hides the Phusion Passenger version number from the ‘Server:’ header too.: Patch submitted by Gregory Potamianos.
Fixed a /proc deprecation warning on Linux kernel >= 3.0.

How do I upgrade to 3.0.12?

Via a gem

First install the gem with the following command:

gem install passenger

If you’re using Phusion Passenger for Apache or for Nginx, then re-run the Apache or Nginx module installer, whichever is appropriate:

passenger-install-apache2-module
passenger-install-nginx-module

At the end the installer will tell you to paste a configuration snippet into your web server config file. Replace the old snippet that you already had with this new one.

Phusion Passenger Standalone users don’t need to run anything else. Whenever you type

passenger start

it will automatically upgrade itself.

Via Ubuntu packages

John Leach from Brightbox has kindly provided Ubuntu packages for Phusion Passenger. You can find installation instructions on the Brightbox website.
(Note that John is currently packaging 3.0.12, so it might take a while before this release shows up in the apt repository.)

Via RedHat/CentOS packages

YUM repositories with RPMs are maintained by Erik Ogan and Stealthy Monkeys Consulting. Please note that Erik is currently packaging 3.0.12, so it might take a while before this release shows up in the yum repositories.

Step 1: install the release package

The easiest way to install Phusion Passenger and keep it up to date is to install the passenger-release package from the main repository:

Fedora Core 15:

yum install http://passenger.stealthymonkeys.com/fedora/15/passenger-release.noarch.rpm

Fedora Core 14:

yum install http://passenger.stealthymonkeys.com/fedora/14/passenger-release.noarch.rpm

RHEL 5 / CentOS 5 / ScientificLinux 5:
(Note: these packages depend on EPEL.)

rpm -Uvh http://passenger.stealthymonkeys.com/rhel/5/passenger-release.noarch.rpm

RHEL 6 / CentOS 6 / ScientificLinux 6:

yum install http://passenger.stealthymonkeys.com/rhel/6/passenger-release.noarch.rpm

Step 2: use Yum

From there you can use Yum to install packages. For example, try one of these:

yum install nginx-passenger

yum install mod_passenger

yum install passenger-standalone

Building your own packages

There are instructions for building your own packages and Yum repositories in the rpm directory ReadMe within the GitHub repository.

Final

Phusion Passenger is provided to the community for free. If you like Phusion Passenger, please consider sending us a donation. Thank you!

Phusion Passenger 3.0.11 released »

Created at: 28.11.2011 14:00, source: Phusion Corporate Blog, tagged: Phusion Passenger

Recent changes

Phusion Passenger is under constant maintenance and development. We are pleased to announce Phusion Passenger version 3.0.11. This is a bug fix release.

3.0.10 was skipped because we discovered a last-minute compilation problem on FreeBSD after having already pushed the gem to RubyGems.org.

[Nginx] Dropped support for Nginx versions older than 1.0.0
[Nginx] Fixed support for Nginx 1.1.4+
[Nginx, Standalone] Upgraded default Nginx version to 1.0.10: The previously default version was 1.0.5.
[Nginx] New option passenger_max_requests: This is equivalent to the PassengerMaxRequests option in the Apache version: Phusion Passenger will automatically shutdown a worker process once it has processed the specified number of requests. Contributed by Paul Kmiec.
[Apache] New option PassengerBufferResponse: The Apache version did not buffer responses. This could block the Ruby worker process in case of slow clients. We now enable response buffering by default. It can be turned off through this option. Feature contributed by Ryo Onodera.
Fixed remaining Ruby 1.9.3 compatibility problems: We already supported Ruby 1.9.3 since 3.0.8, but due to bugs in Ruby 1.9.3′s build system Phusion Passenger would fail to detect Ruby 1.9.3 features on some systems. Fixes issue #714.
Fixed a bug in PassengerPreStart: A regression was introduced in 3.0.8, causing the prespawn script to connect to the host name instead of to 127.0.0.1. Fix contributed by Andy Allan.
Fixed compatibility with GCC 4.6
Affected systems include Ubuntu 11.10.
Fixed various compilation problems.
Fixed some Ruby 1.9 encoding problems.
Fixed some Ruby 1.9.3 deprecation warnings.
Improved performance and solved some warnings on Xen systems by compiling with `-mno-tls-direct-seg-refs`. Patch contributed by Michał Pokrywka.

How do I upgrade to 3.0.11?

Via a gem

First install the gem with the following command:

gem install passenger

If you’re using Phusion Passenger for Apache or for Nginx, then re-run the Apache or Nginx module installer, whichever is appropriate:

passenger-install-apache2-module
passenger-install-nginx-module

At the end the installer will tell you to paste a configuration snippet into your web server config file. Replace the old snippet that you already had with this new one.

Phusion Passenger Standalone users don’t need to run anything else. Whenever you type

passenger start

it will automatically upgrade itself.

Via Ubuntu packages

John Leach from Brightbox has kindly provided Ubuntu packages for Phusion Passenger. The package is available from the Brightbox repository which you can find at:

http://apt.brightbox.net

Add the following line to the Third Party Software Sources:

deb http://apt.brightbox.net hardy main

(The simplest way to do that is to create a file in /etc/apt/sources.list.d/ containing the deb instruction, and then run ‘apt-get update’).

Once you’ve done this then you can install Phusion Passenger by running:

sudo apt-get install libapache2-mod-passenger

-or-

sudo apt-get install nginx-brightbox

(Note that John is currently packaging 3.0.11, so it might take a while before this release shows up in the apt repository.)