Phusion white papers Phusion overview

Phusion Blog

Phusion Passenger 4.0 Release Candidate 6

By Hongli Lai on April 9th, 2013


Phusion Passenger turns Apache and Nginx into a full-featured application server for Ruby and Python web apps. 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 mid-2012, it aims to be the ultimate polyglot application server.

Today we are pleased to announce Release Candidate 6 of Phusion Passenger 4.0. The 4.x series is a huge improvement over the 3.x series: during the development of 4.0, we’ve introduced a myriad of changes which we’ve covered in past beta preview articles:

Release Candidate 5 was a private interim release for Phusion Passenger Enterprise customers only.

Changes in 4.0 RC 5 and RC 6

The most important changes in RC 5 and RC 6 are as follows:

  • The default config snippet for Apache has changed! It must now contain a
    PassengerDefaultRuby option. The installer has been updated to output
    this option. The PassengerRuby option still exists, but it’s only used
    for configuring different Ruby interpreters in different contexts. Please
    refer to the manual for more information.
  • We now provide GPG digital signatures for all file releases by Phusion.
    More information can be found in the manual.
  • WebSocket support on Nginx. Requires Nginx >= 1.3.15.
  • passenger-status now displays process memory usage and time when it
    was last used. The latter fixes issue #853.
  • Exceptions in Rack application objects are now caught to prevent
    application processes from exiting.
  • The passenger-config tool now supports the --ruby-command argument,
    which helps the user with figuring out the correct Ruby command to use
    in case s/he wants to use multiple Ruby interpreters. The manual has
    also been updated to mention this tool.
  • Fixed streaming responses on Apache.
  • Worked around an OS X Unix domain socket bug. Fixes issue #854.
  • Out-of-Band Garbage Collection now works properly when the application
    has disabled garbage collection. Fixes issue #859.
  • Fixed support for /usr/bin/python on OS X. Fixes issue #855.
  • Fixed looping-without-sleeping in the ApplicationPool garbage collector
    if PassengerPoolIdleTime is set to 0. Fixes issue #858.
  • Fixed some process memory usage measurement bugs.
  • Fixed process memory usage measurement on NetBSD. Fixes issue #736.
  • Fixed a file descriptor leak in the Out-of-Band Work feature. Fixes issue #864.
  • The PassengerPreStart helper script now uses the default Ruby
    interpreter specified in the web server configuration, and no longer
    requires a ruby command to be in $PATH.
  • Updated preferred PCRE version to 8.32.
  • Worked around some RVM bugs and generally improved RVM support.
  • The ngx_http_stub_status_module is now enabled by default.
  • Performance optimizations.

Installing and testing 4.0.0 Release Candidate 6

Quick install/upgrade

Phusion Passenger Enterprise users can download the Enterprise version of 4.0 RC 6 from the Customer Area.

Open source users can install the open source version of 4.0 RC 6 with the following commands:

gem install passenger --pre
passenger-install-apache2-module
passenger-install-nginx-module

You can also download the tarball at Google Code.

In-depth instructions

In-depth installation and upgrade instructions can be found in the Installation section of the documentation. The documentation has been updated to cover 4.0 changes, including Enterprise features. You can view them online here:

Final

We are excited about the final release. You can help us by testing RC 6 and reporting any bugs. Please submit bug reports to our bug tracker.

We at Phusion are regularly updating our products. Want to stay up to date? Fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



Phusion Passenger 4.0 Release Candidate 4

By Hongli Lai on March 5th, 2013


Phusion Passenger turns Apache and Nginx into a full-featured application server for Ruby and Python web apps. 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 mid-2012, it aims to be the ultimate polyglot application server.

Today we are pleased to announce Release Candidate 4 of Phusion Passenger 4.0. Last week we said that the open source release of Release Candidate 1 will be out today. However because of the helpful feedback and bug reports we’ve received from Enterprise customers, we’ve decided to push out these bug fixes to the open source version earlier. Release Candidate 3 was only available for Enterprise customers in order to test bug fixes, so it hasn’t been announced publicly.

The 4.x series is a huge improvement over the 3.x series: during the development of 4.0, we’ve introduced a myriad of changes which we’ve covered in past beta preview articles:

Changes in 4.0 RC 3 and RC 4

The focus of RC 3 and RC 4 have yet again been on improving stability. We’ve closed over 50 issues in our issue tracker.

The most important changes in RC 3 and RC 4 are as follows:

  • Fixed Rake autodetection.
  • Fixed compilation on systems where /tmp is mounted noexec.
  • Fixed some memory corruption bugs.
  • Phusion Passenger Standalone now sets underscores_in_headers. Fixes issue #708.
  • Fixed some process spawning compatibility problems, as reported in issue #842.
  • The Python WSGI loader now correctly shuts down client sockets even when there are child processes that keep the socket open.
  • A new configuration option PassengerPython (Apache) and passenger_python (Nginx) has been added so that users can customize the Python interpreter on a per-application basis. Fixes issue #852.
  • The Apache module now supports file uploads larger than 2 GB when on 32-bit systems. Fixes issue #838.
  • The Nginx version now supports the passenger_temp_dir option.
  • Environment variables set in the Nginx configuration file (through the env config option) are now correctly passed to all application processes. Fixes issue #371.
  • Fixed support for RVM mixed mode installations. Fixes issue #828.
  • Phusion Passenger now outputs the Date HTTP header in case the application didn’t already do that (and was violating the HTTP spec). Fixes issue #485.
  • Phusion Passenger now checks whether /dev/urandom isn’t broken. Fixes issue #516.
  • Improved debugging messages.

Installing and testing 4.0.0 Release Candidate 4

Quick install

Phusion Passenger Enterprise users can download the Enterprise version of 4.0 RC 4 from the Customer Area.

Open source users can install the open source version of 4.0 RC 4 with the following commands:

gem install passenger --pre
passenger-install-apache2-module
passenger-install-nginx-module

You can also download the tarball at Google Code.

In-depth

In-depth installation and upgrade instructions can be found in the Installation section of the documentation. The documentation has been updated to cover 4.0 changes, including Enterprise features. You can view them online here:

Final

We are excited about the final release. You can help us by testing RC 4 and reporting any bugs. Please submit bug reports to our bug tracker.

We at Phusion are regularly updating our products. Want to stay up to date? Fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



Phusion Passenger 4.0 Release Candidate 2

By Hongli Lai on February 27th, 2013


Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

We know many users are eagerly awaiting the final release of Phusion Passenger 4.0. The 4.x series is a huge improvement over the 3.x series: during the development of 4.0, we’ve introduced a myriad of changes which we’ve covered in past beta preview articles:

Today we are proud to announce Release Candidate 2 of Phusion Passenger 4.0. Release Candidate 1 has been skipped because a few bug fixes were applied right after RC 1 was tagged.

Changes in 4.0 RC 1 and RC 2

The focus of RC 1 and RC 2 have been on improving stability and on refining previously introduced features. We’ve closed over 100 issues in our issue tracker. We couldn’t have done this without the fantastic feedback from our users, especially those from many Phusion Passenger Enterprise customers who have beta tested the RC previews in their staging environments.

The changes in RC 1 and RC 2 are as follows:

  • The Nginx version now supports the passenger_app_root configuration option.
  • The Enterprise memory limiting feature has been extended to work with non-Ruby applications as well.
  • Application processes that have been killed are now automatically detected within 5 seconds. Previously Phusion Passenger needed to send a request to the process before detecting that it’s gone. This change means that when you kill a process by sending it a signal, Phusion Passenger will automatically respawn it within 5 seconds (provided that the process limit settings allow respawning).
  • Phusion Passenger Standalone’s HTTP client body limit has been raised from 50 MB to 1 GB.
  • Python 3 support has been added.
  • The build system has been made compatible with JRuby and Ruby 2.0. This does not mean that Phusion Passenger works on Ruby 2.0; please read on for more about this subject.
  • The installers now print a lot more information about detected system settings so that the user can see whether something has been wrongly detected.
  • Some performance optimizations. These involve further extending the zero-copy architecture, and the use of hash table maps instead of binary tree maps.
  • Many potential crasher and freezer bugs have been fixed.
  • Error diagnostics have been further improved.
  • Many documentation improvements.

What about Ruby 2.0?

UPDATE June 6 2013: Phusion Passenger 4.0.0 fully supports Ruby 2.0! See this article for clarification.

We are just as excited about Ruby 2.0 as many of you are. Since 2.0 was released a few days ago, we’ve been testing Phusion Passenger on it. We really wanted to release RC 2 with Ruby 2.0 support, but a few things stood in our way so we had to postpone this goal.

  • We couldn’t get Ruby 2.0.0 installed on OS X Mountain Lion. The compiled Ruby crashes during Ruby 2.0.0’s build process with a low-level error ([BUG] Stack consistency error). Apparently we aren’t the only ones.
  • We were able to get it installed on a Debian VM, but it does not pass all the Phusion Passenger unit tests. It fails on some tests with obscure errors that seem to indicate bugs in Ruby, e.g. errors in which Ruby cannot figure out where the exception came from.

We recommend sticking with 1.9.3 in the mean time until the next Ruby 2.0 patchlevel release.

Release Candidate 2 timeline & download

Phusion Passenger Enterprise customers are given priority access to Release Candidate 2. They can download RC 2 from the Customer Area immediately.

Phusion Passenger Enterprise customers: download RC 2 from Customer Area

The release of the open source version will follow in one week, on March 5 2013. Of course, open source users who want to stay on the bleeding edge are free to obtain the latest sources from the open source Phusion Passenger git repository at any time.

When the open source version is released, users can install it by following the in-depth installation and upgrade instructions in the Installation section of the documentation. The manual also covers installation of beta releases.

Final

We are excited about the final release. You can help us by testing RC 2 and reporting any bugs. Please submit bug reports to our bug tracker.

We at Phusion are regularly updating our products. Want to stay up to date? Fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



Phusion Passenger 4.0 beta 2: Syscall failure simulation framework, focus on stability

By Hongli Lai on January 24th, 2013


Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

Development of the Phusion Passenger 4.x series is progressing steadily. The 4.x series is a huge improvement over the 3.x series: in the announcement for Phusion Passenger 4.0.0 beta 1, we introduced a myriad of changes such as support for multiple Ruby versions, Python WSGI support, multithreading (Enterprise only), improved zero-copy architecture, better error diagnostics and more. That was just the beginning, because soon after we announced JRuby and Rubinius support, Out-of-Band Work and the Rack socket hijacking API.

Today we are proud to announce Phusion Passenger 4.0 beta 2, which brings us closer to a final release.

Better stability, documentation, test coverage

Beta 1 was usable, but not yet production-ready. While it worked well most of the time, there were some bugs that could cause crashes. So for beta 2 we haven’t introduced too many new features. Instead we’ve been focussing a lot on fixing bugs, improving stability, improving documentation and improving test coverage. It is easy to fall into the trap of constantly adding features, but we want a rock-solid product that our users and customers can rely on.

How do we ensure quality? There are a few tools and techniques that we use:

System call failure simulation framework

SQLite
Our inspiration

The system call failure simulation framework is a new developer feature in 4.0 beta 2 and allows us to simulate random system call failures so that we can test whether error handling in Phusion Passenger is done correctly. Although we already test for many error handling scenarios in our unit tests, test coverage is not perfect. This framework gives us another tool to ensure quality.

A few months ago we sat down with a customer who was experiencing seemingly random crashes with Phusion Passenger. These crashes could not be reproduced on any of our systems, but could be reliably reproduced on theirs. The crashes would only manifest under high concurrency scenarios. After a day of intensive investigation, we found that the crash was caused because their systems’ file descriptor limit is much lower than any of our systems’. Phusion Passenger did not always catch out-of-file-descriptors errors, so those errors caused Phusion Passenger to crash. Due to other unrelated issues, relevant error messages could not be printed to the log file and were lost.

All of those issues have since been fixed, but it made us realize that our testing tools were not adequate. That situation could and should have been prevented. Thus, the system call failure simulation framework was born. This framework allows us to specify which system calls should fail, and with what probability. For example, the following configuration simulates the “out of file descriptors” error in the helper agent with a probability of 1%.

export PASSENGER_SIMULATE_SYSCALL_FAILURES=PassengerHelperAgent=ENFILES=0.01

Different runs will produce different errors, but you can force determinism by specifying the same random seed that was used in the last run. The random seed is printed as a debugging message during startup and during crash.

export PASSENGER_RANDOM_SEED=...

The system call failure simulation framework was inspired by SQLite’s testing process. Real hardware, network or OS-level errors are difficult to create, so simulating them is the next best thing. SQLite has an internal virtual filesystem layer, and it is in that layer that they simulate failures. In our case we have a similar layer, namely the system call interruption framework which was originally written to facilitate interrupting threads that are blocked on blocking system calls.

Continuously expanding and improving our test suite

We already had an extensive test suite which consists of a hybrid of C++ and Ruby RSpec code. In 4.0 beta 2 we’ve improved the test suite by modernizing some dependencies, testing more edge cases, testing more failure conditions, etc.

Setting up Continuous integration

Before today our extensive test suite was run on our development machines as well as an army of virtual machines with different OSes. We have now setup Travis CI so that we would have an additional quality assurance tool. The test suite has also been extended to cover more cases.

Ruby 1.8 is now considered legacy

Ruby 1.9 is the future
Ruby 1.8 is no longer supported by its authors, and Ruby Enterprise Edition has been End-Of-Lifed a while ago. Many gems these days are Ruby 1.9-only. It is more than apparent that Ruby 1.8 is considered legacy by the community, and for good reasons. We too are joining the community by considering Ruby 1.8 legacy. This has the following implications:

  • Phusion Passenger 4.x will continue to support Ruby 1.8. Our support goes as far back as Ruby 1.8.5.
  • We will optimize performance for Ruby 1.9. Phusion Passenger will still work on Ruby 1.8, but we will no longer put in any effort to make it work fast on Ruby 1.8.

Installing and testing 4.0.0 beta 2

Quick install

Phusion Passenger Enterprise users can download the Enterprise version of 4.0 beta 2 from the Customer Area.

Open source users can install the open source version of 4.0 beta 2 with the following commands:

gem install passenger --pre
passenger-install-apache2-module
passenger-install-nginx-module

You can also download the tarball at Google Code.

In-depth

In-depth installation and upgrade instructions can be found in the Installation section of the documentation. The documentation has been updated to cover 4.0 changes, including Enterprise features. You can view them online here:

Final

We are excited about the final release. You can help us by testing beta 2 and reporting any bugs. Please submit bug reports to our bug tracker.

We at Phusion are regularly updating our products. Want to stay up to date? Fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



The new Rack socket hijacking API

By Hongli Lai on January 23rd, 2013


Yesterday saw the release of Rack 1.5.0, which adds a new feature to the Rack specification dubbed socket hijacking. This feature allows applications to take over the client socket and perform arbitrary operations on it, e.g. implementing WebSockets, streaming data to the client, etc.

Did Rack not support streaming? Actually yes it did, you can do it by returning a body object that outputs body chunks in the #each method, as explained in our past article Why Rails 4 Live Streaming is a Big Deal. But this API is a bit clunky. The socket hijacking API provides access to a Ruby IO object-like API.

Support for socket hijacking has been added to Phusion Passenger 4 yesterday. The upcoming Phusion Passenger 4 has been covered here, here and here. Phusion Passenger Enterprise customers can already test and enjoy a preview of this feature by downloading the “3.9.2 beta preview (4.0.0 beta 2)” file from the Customer Area.

The socket hijacking API was surprisingly easy to implement, but unfortunately poorly documented at this time. The application-level API is not immediately obvious, and the Rack specification documentation has not yet been updated to cover the hijacking API. In this article we’ll introduce the API and provide an example program.

What the socket hijacking API is not

Some of you may have heard of efforts to develop a “Rack 2.0” specification which properly covers things such as streaming and evented servers. According to the hijacking API developer, this API is not an attempt towards Rack 2.0. It is a “good enough” solution that works within the confines of the Rack 1.x specification. Things may change in Rack 2.0, though at this time it’s unclear what the progress towards Rack 2.0 is.

It is also unclear whether the API is supposed to be final or not. While implementing this API and writing this article we’ve discovered some room for improvement. The suggestions (which you can find later in this article) have been submitted to the developers.

Overview of the API

The hijacking API provides two modes:

  1. A full hijacking API, which gives the application complete control over what goes over the socket. In this mode, the application server doesn’t send anything over the socket, and lets the application take care of it. This mode is useful if you want to implement arbitrary (even non-HTTP) protocols over the socket. This is subject to limitations: if your application is behind a web server or an HTTP load balancer then those components dictate which protocols you can implement.
  2. A partial hijacking API, which gives the application control over the socket after the application server has already sent out headers. This mode is mostly useful for streaming.

The hijacking API is accessible through the Rack env hash. You can check whether the application server supports the hijacking API by checking env['rack.hijack?'], which returns a boolean value.

Full hijacking

You can perform a full hijack by calling env['rack.hijack'].call. You can access the hijacked socket object through env['rack.hijack_io']. Phusion Passenger’s implementation of env['rack.hijack'] returns the socket object, but it is unclear whether this is supposed to be standard behavior.

You are responsible for:

  • Outputting any HTTP headers, if applicable.
  • Closing the IO object when you no longer need it.

You should output the “Connection: close” header unless you plan on implementing HTTP keep-alive yourself.

Here’s am example of the full hijacking API in action:

# encoding: utf-8
require 'thread'

# Streams the response "Line 1" .. "Line 10", with
# 1 second sleep time between each line.
# 
# Non-Phusion Passenger users may have to turn off their
# web servers' buffering options for streaming to work.
# Phusion Passenger 4 users don't have to do anything, it
# works out-of-the-box thanks to our real-time response
# buffering feature.
app = lambda do |env|
  # Fully hijack the client socket.
  env['rack.hijack'].call
  io = env['rack.hijack_io']
  begin
    io.write("Status: 200\r\n")
    io.write("Connection: close\r\n")
    io.write("Content-Type: text/plain\r\n")
    io.write("\r\n")
    10.times do |i|
      io.write("Line #{i + 1}!\n")
      io.flush
      sleep 1
    end
  ensure
    io.close
  end
end

run app

Partial hijacking

You can perform a partial hijack by assigning a lambda to the rack.hijack response header. This lambda will be called after the application server has sent out headers. The application server will ignore the body part of the Rack response, and will call the ‘rack.hijack’ lambda, passing it the client socket. You are responsible for closing the socket when it’s no longer needed.

It is unclear what the value of the Rack response body should be. Phusion Passenger’s implementation doesn’t care: you can return a two-array response, or a three-array response where where the body can be anything. If the ‘rack.hijack’ response header is set, the body will be completely ignored.

Example:

# encoding: utf-8
require 'thread'

# Streams the response "Line 1" .. "Line 10", with
# 1 second sleep time between each line.
# 
# Non-Phusion Passenger users may have to turn off their
# web servers' buffering options for streaming to work.
# Phusion Passenger 4 users don't have to do anything, it
# works out-of-the-box thanks to our real-time response
# buffering feature.
app = lambda do |env|
  response_headers = {}
  response_headers["Content-Type"] = "text/plain"
  response_headers["rack.hijack"] = lambda do |io|
    # This lambda will be called after the app server has outputted
    # headers. Here we can output body data at will.
    begin
      10.times do |i|
        io.write("Line #{i + 1}!\n")
        io.flush
        sleep 1
      end
    ensure
      io.close
    end
  end
  [200, response_headers, nil]
end

run app

Issues with the hijacking API

Here’s how we think the hijacking API can be improved.

  • env['rack.hijack?'] appears to be unnecessary. You can already check for hijacking support by checking env['rack.hijack'].
  • The partial hijacking API should not involve assigning a lambda to the response headers. As far as we can see, you can just return the lambda as the body. That would be a much more elegant solution.
  • The return value for env['rack.hijack'] should be well-defined.

Conclusion

The Rack hijacking API, while having some quirks in our opinion, gets the job done. We hope that the usage of the hijacking API has become more clear after reading this article. If you have any comments, questions, suggestions or corrections, please let us know.

We at Phusion are working feverishly at the upcoming Phusion Passenger 4 (covered here, here and here). Implementing the hijacking API so quickly is our way of showing you how dedicated we are. Together with Phusion Passenger Enterprise, we aim to deliver the most stable, performant and feature rich polyglot application server out there. If you’re interested in future updates, please subscribe to our newsletter. Until next time!



Phusion Passenger 4 Technology Preview: Out-Of-Band Work

By Hongli Lai on January 22nd, 2013


Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

Development of the Phusion Passenger 4.x series is progressing steadily. The 4.x series is a huge improvement over the 3.x series: in the announcement for Phusion Passenger 4.0.0 beta 1, we introduced a myriad of changes such as support for multiple Ruby versions, Python WSGI support, multithreading (Enterprise only), improved zero-copy architecture, better error diagnostics and more. That was just the beginning, because soon after we announced JRuby and Rubinius support. Today we are announcing another cool feature.

Out-of-Band Work

The Out-of-Band Work feature allows one to perform arbitrary long-running work outside request cycles without blocking HTTP clients. The primary use case is to run the garbage collector in between request cycles so that your requests will finish faster because they will be interrupted less by the garbage collector.

Normally the garbage collector fires up as soon as the Ruby interpreter thinks it needs to, which possibly results in hundreds of milliseconds of latency. With the Out-of-Band Work feature, you can run the garbage collector outside the request cycles so that garbage collection runs inside cycles are much less expensive. While out-of-band work is running, Phusion Passenger will not route any requests to said process.

Cool properties of this feature:

  • If the process that triggered Out-Of-Band Work is the only process for that application, then Phusion Passenger will first spawn up a new process before performing the out-of-band work. When the out-of-band work has finished, the process will be eligible for idle timeout cleaning. Thus you can use this feature in any scenario, and Phusion Passenger will do the right thing for you.
  • It even works in multithreaded setups (an Enterprise-only feature). Normally the Ruby garbage collector will block all threads while doing work. So before performing the out-of-band work, Phusion Passenger will let all existing requests to the application process finish.
Before Out-Of-Band GC After Out-Of-Band GC
Before and after applying out of band GC at AppFolio

This awesome feature has been contributed by AppFolio. They’ve been running it in production for a while now with quite some success. Average response time has gone down by 100 ms.

Compared to Unicorn’s OOBGC

Users who are familiar with Unicorn’s Out-of-Band GC (OOBGC) might notice the similarities. Our Out-of-Band Work feature (OOBW) is more general and more flexible:

  • Unicorn’s OOBGC requires a static number of single-threaded workers. OOBW is designed to be able to handle a dynamic number of workers that may even be multithreaded.
  • OOBW is designed to be able to perform arbitrary long-running work, including work that may block all threads. Unicorn’s OOBGC only works with garbage collection.

Using Out-Of-Band Work

Note January 31 2014: the following code snippet is outdated and no longer works on the latest version of Phusion Passenger. Please refer to the Phusion Passenger manual for the latest, correct, code snippet.

Phusion Passenger 4.0 beta 2 provides a simple Rack middleware that you can use to enable out-of-band GC:

if defined?(PhusionPassenger)
  require 'phusion_passenger/rack/out_of_band_gc'
  # Trigger out-of-band GC every 5 requests.
  use PhusionPassenger::Rack::OutOfBandGc, 5
  ## Optional: disable normal GC triggers and only GC outside
  ## request cycles. Not recommended though, see section
  ## "What Ruby can do to improve out-of-band garbage collection"
  # GC.disable
end

It also provides a simple API to perform Out-Of-Band Work. For example out-of-band GC may be implemented as follows without using the Rack middleware:

# Somewhere in a controller method:
# Tell Phusion Passenger we want to perform OOB work.
response.headers["X-Passenger-Request-OOB-Work"] = "true"

# Somewhere during application initialization:
if defined?(PhusionPassenger)
  PhusionPassenger.on_event(:oob_work) do
    # Phusion Passenger has told us that we're ready to perform OOB work.
    t0 = Time.now
    GC.start
    Rails.logger.info "Out-Of-Bound GC finished in #{Time.now - t0} sec"
  end
end    

## Optional: disable normal GC triggers and only GC outside
## request cycles. Not recommended though, see section
## "What Ruby can do to improve out-of-band garbage collection"
# GC.disable

Inside Out-Of-Band Work: a more general mechanism

The Out-Of-Band Work feature is actually built on top of an even more general mechanism: the enable/disable process feature. This is a new feature in Phusion Passenger 4 and is, for now, internal only. Internal Phusion Passenger code can mark a process as disabled, so that Phusion Passenger will no longer route requests to it. But the actual process is kept alive. Internal code can reenable the process later, making it eligible again for processing requests.

This feature is simple to use and simple to understand, but was tricky to implement. Phusion Passenger works in a heavily concurrent environment so it may not be able to disable a process immediately. The process might be handling requests, it might be restarting, another process might be spawning, etcetera. The entire API follows an asynchronous design. If the to-be-disabled process is the only process for that application, then Phusion Passenger will spawn another process. Disabling the original process will complete when the new process has been spawned, and the original process is done processing all its requests.

Once the enable/disable feature was in place, implementing Out-Of-Band Work was almost trivial. When an application wants to perform Out-Of-Band Work, it sends a signal to Phusion Passenger. We currently use the X-Passenger-OOB-Work header to do this, which is filtered out by Phusion Passenger and will never reach the client. Phusion Passenger will then try to disable the process. Once disabled, Phusion Passenger will send a signal to the application, telling it that it may proceed to perform out-of-band work. At this point the process is guaranteed not to be processing any requests, so it can freely do whatever it wants. Once the out-of-band work has finished, Phusion Passenger will reenable the process.

This simple mechanism opens the door to many other possibilities that are currently not implemented:

  • In the future we can add an admin command to access the API, so that the administrator can disable/enable processes. That way the administrator can temporarily isolate a process for debugging without disrupting production traffic.
  • Phusion Passenger Enterprise’s live IRB console feature can optionally disable the process before attaching itself, so that the administrator can debug the process without him being disrupted by traffic.

What Ruby can do to improve out-of-band garbage collection

The currently recommended mode is to run the out-of-band garbage collection with the normal Ruby garbage collector turned on. This significantly reduces the latency of normal garbage collection runs, but does not eliminate them. It is possible to completely eliminate normal garbage collection latency by disabling the garbage collector so that garbage collection is only performed out-of-band, but this will result in high peak memory usage because:

  • There’s currently no way to find out when the Ruby garbage collector needs to be run. The “every x requests” option is a suboptimal heuristic.
  • The MRI Ruby interpreter does not support heap compaction, so even when memory has been reclaimed by the garbage collector, Ruby may not be able to return that memory to the operating system.

It would be great if Ruby can address both issues. This will improve the usefulness of out-of-band garbage collection significantly.

Conclusion

Out-of-Band Work will become part of Phusion Passenger 4.0 beta 2, which will be released very soon. Phusion Passenger Enterprise customers can already test and enjoy this feature by downloading the “3.9.2 preview (4.0.0 beta 2)” file from the Customer Area.

Please stay tuned for further announcements on Phusion Passenger 4. If you like, you can subscribe to our newsletters and we’ll keep you up to date.



Phusion Passenger Enterprise – Nedap Healthcare Case Study

By Ninh Bui on November 12th, 2012

Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

Phusion Passenger is being used by a myriad of companies, ranging from small businesses to billion dollar companies. In this series of video case studies, we will learn more about the various companies using Phusion Passenger and how they use Phusion Passenger for their day to day operations. In this very first video case study, we will visit our friends over at Nedap.

Nedap Healthcare Case Study

Nedap is a publicly traded tech company with reported annual revenues of over $100MM. With activities branching into healthcare, it is important for their systems to be available at all times. Especially if they’re being used by over 150,000 clients on a day to day basis, resulting in billions of requests. In this case study, we will learn how Phusion Passenger Enterprise has contributed to their way of doing business care-free for the past 4 years.

Interested in sharing your story too?

It’s no secret that we’re pretty passionate about our products. If there is however one thing we’re even more passionate about, it would be our customers. If you’re using Phusion Passenger and would like to share your experiences in hosting your app, we’d love to know! Please contact us via email if you’re interested in doing a (similar) case study. And please include the word “notspam” in your email to bypass our spam filters.

Interested in future case studies? Sign up for the mailing list and we’ll keep you up to date. No spam, we promise. Unsubscribe any time.



Phusion Passenger 4.0 beta 1 is here

By Hongli Lai on October 24th, 2012


Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

The 3.0 series brought forth many architectural and feature improvements and has lasted us for a long time, but it’s finally time to move on to the next big thing. We are proud to introduce the first beta of the Phusion Passenger 4.0 series which introduces exciting new features, much improves scalability and concurrency, lifts many old limitations and dramatically improves the internal architecture. We blogged extensively about 4.0 in the past (see part 1 and part 2, as well as these blog posts).

At the same time, we’ve also released Phusion Passenger Enterprise 4.0 beta 1, which contains all these changes. Enterprise customers can download it from the Customer Area.

What’s new?

For your convenience, we’ve compiled the full list of changes in 4.0. It should be noted that these changes are only the beginning. The new architecture opens the door for many exciting future improvements, which we will blog about in the near future.

Multiple Ruby versions


You can now run multiple Ruby versions at the same time in the same Phusion Passenger instance. This allows you to run some apps in Ruby 1.8 and some apps in Ruby 1.9, for example.

In Phusion Passenger tradition, using this feature is a breeze. We’ve now made the PassengerRuby/passenger_ruby option per-vhost instead global so you can set a different value per application. Phusion Passenger then takes care of the rest.

Evented I/O internally

Phusion Passenger’s I/O handler has been completely rewritten and is now evented, just like Nginx and Node.js. Evented I/O brings forth many scalability benefits. Phusion Passenger can now handle a virtually unlimited number of connections (high I/O concurrency support), limited only by system resources such as memory, CPU and OS file descriptor limits.

Why is being evented and being able to support a high I/O concurrency such a big deal? There are several reasons.

  • Lifting request queuing limits.

    Previously, Phusion Passenger’s internal I/O was multithreaded. On Apache, Phusion Passenger would have as many I/O threads as there were Apache processes/threads. On Nginx, Phusion Passenger would have 4 * passenger_max_pool_size I/O threads.

    Suppose that an application is handling a long-running request, but that application is temporarily receiving a lot of traffic. Phusion Passenger will then queue all those requests and will wait for the application to become available to handle more requests. It only takes a small number of requests to be queued up before Phusion Passenger runs out of I/O concurrency, meaning that Phusion Passenger cannot handle requests for other applications even when they’re available.

    The problem is shown schematically in the following figure.

    4 clients (denoted A) are sending long-running requests to the server. The kernel dispatches these requests over the 4 I/O threads, which forward the request to the application process foo.com. The server only has 4 I/O threads so it has now run out of I/O concurrency. In the mean time, another client (denoted B) sends another request, meant for bar.com. The application process bar.com is obviously available for work, but it cannot be reached because the I/O threads are still busy.

    Evented I/O lifts this limit completely. There are no I/O threads and each request can be handled immediately as soon as the corresponding application process becomes available.

  • Lower virtual memory usage.

    A thread uses a fixed amount of virtual memory at minimum thanks to its stack. We set a custom thread stack size of 256 KB. With evented I/O, there is only 1 I/O thread, so the overhead is even lower.

  • Real-time response buffering support.

    The real-time response buffering feature, which this article describes later, depends on the ability to support high I/O concurrency.

  • Support for applications that block a lot on external I/O.

    If the application blocks on a lot of external I/O, e.g. if it performs a lot of HTTP API calls, then the I/O core must either be evented or heavily multithreaded. The “Multithreading within Ruby apps” subsection explains this in detail.

  • Non-HTTP protocol support.

    Evented I/O allows us to support non-HTTP protocols in the future, e.g. WebSockets.

It should be noted that to fully enjoy the benefits of evented I/O, your web server must also be able to support high I/O concurrency. Nginx and Phusion Passenger Standalone already support this by default. On Apache you may have to increase your number of processes or worker threads. If you really need a lot of I/O concurrency then we recommend you to use the worker MPM.

It should also be noted that only Phusion Passenger itself has become evented. Phusion Passenger still hosts applications as multiple single-threaded processes. However Phusion Passenger Enterprise 4 is also able to host applications as multi-threaded processes; read on for more!

Real-time response buffering

Many web applications depend on the web server to buffer the output in order to protect themselves from slow client. In multi-process architectures, you really don’t want to block the application while output is being sent to the client, because the client can take an arbitrary amount of time to receive the response. Unicorn for example is completely designed around the architecture of letting the web server take care of slow clients.

However this setup has some limitations. Web servers traditionally buffer the entire response before sending it to the client. This also means that it’s not easily possible to flush partial response data to the client immediately. Rails 3.2 streaming depends on this ability, which is why Unicorn + Nginx + Rails 3.2 streaming can be problematic.

This becomes even more problematic if you have a long-running request but you want to send progress data to the client periodically. For example, consider the following use case where we fetch 1 million database records, compresses them into an archive file, and emails it to the user. While we’re fetching and creating the archive file we want to tell the user what the progress is.

zip     = ZipFile.new("archive.zip")
total   = DatabaseRecord.count
counter = 0

DatabaseRecord.each do |record|
  zip.append(record.name, record.data)
  counter += 1
  if counter % 100 == 0
    # We report the progress every 100 records.
    response.stream.write("Progress: #{counter}/#{total}\n")
  end
end

zip.close
response.stream.write("Done!\n")

The above example also depends on the ability to immediately flush data to the client. If the web server buffers the entire response first then the user will not see a smooth progress report.

Phusion Passenger 4 introduces real-time response buffering. Unlike traditional response buffering, Phusion Passenger sends data to the client immediately, while still relieving the application from slow clients. It works by reading the response as quickly as possible from the application, while concurrently sending the response as quickly as possible to the client.

Real-time response buffering architecture

This works even with very large responses: it buffers a limited amount of data in memory, and if there’s more data it will buffer to disk instead. Now you can send multi-megabyte responses without worrying about introducing latency because of buffering. You can now safely use the Rails send_file method without worrying about it being too slow.

You don’t need to turn real-time response buffering on, it’s enabled by default. Now application developers need never worry about response buffering anymore, it Just Works™ and does the right thing.

Zero-copy architecture

Phusion Passenger 4 has a much more advanced zero-copy architecture than Phusion Passenger 3. In most performance-critical places we now avoid copying data whenever we can. The zero-copy architecture is implemented by using scatter-gather I/O calls 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:

  1. 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.
  2. 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

Normal I/O requires many system calls or a temporary buffer for concatenation. Scatter/gather I/O allows writing multiple buffers in a single system call.

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 4 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.

Rewritten ApplicationPool and process spawning subsystem

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 other large subsystem is the process spawning subsystem (SpawnManager and friends), which takes care of the details of process spawning. This subsystem is what implements smart spawning (similar to preload_app true if you’re familiar with Unicorn).

The old ApplicationPool and process spawning subsystem has lasted for a long time, and they were not without issues. The ApplicationPool had a large lock that would be held whenever the first process for an application is being spawned. Only after the first application process has been spawned can subsequent processes be spawned in the background. While the lock is held, Phusion Passenger is unable to handle any requests.

The ApplicationPool and process spawning subsystems have been entirely rewritten in Phusion Passenger 4. They no longer have a large lock that must be held for a long time. The design is completely asynchronous. The subsystems are now:

  • Faster. Critical code paths are carefully optimized in C++ for performance, and require less thread context switching. Critical parts are now zero-copy.
  • More stable. The new spawning subsystem has a lot of error checking code.
  • More maintainable. The old subsystems were hard to read and hard to extend. The new subsystems are much more modular and are very well-tested.
  • More DRY. A part of the old process spawning subsystem was implemented in Ruby, but this means that a lot of code had to be duplicated between Ruby and Python support code. Now that the majority has been moved into C++, the Ruby and Python launchers are extremely lightweight.
  • Less memory hungry, thanks to the DRYness.
    • 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.

Multithreading within Ruby apps (Phusion Passenger Enterprise only)

In Why Rails 4 Live Streaming is a big deal, we explained that single-threaded pure multiprocessing is not a good I/O model for supporting high concurrency I/O uses, such as apps that make a lot of HTTP API calls.

We used to be big proponents of single-threaded pure multiprocessing when it comes to the context of web apps. Multiprocessing solved a lot of threading-related problems, had wide support in the Ruby ecosystem, and memory savings could be achieved through the use of copy-on-write as provided by Ruby Enterprise Edition (our branch of Ruby 1.8 that had a copy-on-write friendly garbage collector), was well suited to typical web app I/O patterns at the time, provided some form of fault tolerance (a crashing/freezing process would not take the entire web app down) and allowed utilizing multiple CPU cored.

However, times and requirements have changed. We believe multiprocessing is no longer sufficient for many of today’s applications. Together with the end-of-life of Ruby Enterprise Edition, we believe that a hybrid between multiprocessing, multithreading and evented is the way forward. The Ruby ecosystem these days has excellent support for multithreading. A limited number of processes together with a larger number of threads, or just a limited number of evented processes, also saves a lot more memory than copy-on-write multiprocessing did.

Phusion Passenger Enterprise 4 is the first step towards this hybrid multiprocessed, multithreaded and evented I/O model. It supports multithreading within Ruby apps. For optimal backward compatibility, the default is still multiprocessing. Enabling multithreading support is a breeze, requiring only 2 configuration options:

PassengerConcurrencyModel thread
PassengerThreadCount 32

Python WSGI support lifted to “beta” status


It is a little known fact that we have supported Python WSGI since mid-2008. However, WSGI support remained “proof of concept”. We are now lifting WSGI support to “beta” status, which means that we make an effort to make it work and that there’s documentation available. This is the first step towards our goal of becoming a polyglot application server.

WSGI support in Phusion Passenger 3 and earlier required Ruby, but in version 4 this requirement has been removed because a lot of functionality has been migrated from Ruby to C++. Phusion Passenger now only requires Ruby for a limited number of things:

  • The build system.
  • Ruby application support.
  • The PassengerPreStart feature.

More protection against stuck processes

Phusion Passenger 4 offers more protection against stuck application processes. The following cases are covered:

  • During web server shutdown. Previously, when the web server was being shut down, Phusion Passenger would only gracefully ask application processes to shut down. This didn’t work for stuck processes. Phusion Passenger 4 forcefully cleans up all processes when the web server is shut down. This makes everything much more reliable in case there are problems.
  • During spawning of new application processes.

Additionally, Phusion Passenger Enterprise also offers protection against processes that are stuck during a request.

Automatically picks up environment variables from your bashrc

Setting environment variables has traditionally been a huge usability problem with Phusion Passenger. Many users expect that environment variable settings in their bashrc would affect Phusion Passenger. It does not, because the web server tends to be started in a completely different environment, not invoked from bash. Setting environment variables required special instructions that were not so obvious to people who are inexperienced with Unix.

Although this usability problem is not our fault, we consider it to be our problem and we feel that addressing it is in line with the Phusion Passenger philosophy. Phusion Passenger 4 therefore automatically picks up environment variables, umasks, ulimits or whatever other settings from your bashrc! This is implemented by starting all application processes through “bash -li”, but obviously only if the user that the application runs under has bash set as his/her shell.

Setting environment variables directly in Apache

You can now set environment variables directly in Apache using PassEnv and SetEnv. Previously, this would not always work as expected because application processes are forked off from a spawn manager process that was written in Ruby. Spawning application processes did not involve an exec(), so setting environment variables like LD_LIBRARY_PATH would have no effect.

In Phusion Passenger 4, application processes are started in a different way, so PassEnv and SetEnv now work as expected.

Better error messages and error diagnostics

The new error page in action, with tons
of details for analyzing the problem.

With Phusion Passenger we’ve always tried to make our error logs as clear and useful as possible. Phusion Passenger 4 marks a new milestone in this effort. Now whenever Phusion Passenger’s C++ code crashes for whatever reason, it will print a more detailed crash report to the error log of the web server, including a backtrace and a bunch of information about the environment that is relevant to the crash.

This feature makes sure that whenever Phusion Passenger crashes, be it due to an operating system error, or a problem with Passenger itself, you are equipped with the knowledge you need to deal with the issue quickly and effectively. The crash handler behavior is configurable.

The error page, which is shown in your browser when your application fails to start, has been much improved. It now contains detailed information about your environment, such as the Ruby version, environment variables, user and group ID, ulimits, etc. Deployment problems now become easier to debug than ever.

Automatic asset pipeline support in Standalone

The Rails guides recommend that files generated by the asset pipeline should have a far-future expiration date and that they should max out any caching headers. But configuring these options in a fully correct way can be quite tedious. Phusion Passenger Standalone alleviates this problem by automatically configuring Nginx with the right settings.

Deleting restart.txt no longer triggers a restart

When restart.txt no longer exists, Phusion Passenger would consider this to be a sign to restart the application. This interfered with some Capistrano deployments, so deleting restart.txt will no longer trigger a restart.

Installation & documentation

You can install the open source version of 4.0 beta 1 with the following commands:

gem install passenger --pre
passenger-install-apache2-module
passenger-install-nginx-module

You can also download the tarball at Google Code.

Phusion Passenger Enterprise users can download the Enterprise version of 4.0 beta 1 from the Customer Area.

Documentation is available under the doc/ directory in the source tree. You can view them online here:

Note that these are temporary links for the beta documentation, and they will eventually be removed. Please don’t link to them.

And because this is a beta, not everything may work correctly. Please submit bug reports to our bug tracker.

Final

The open source Phusion Passenger is provided to the community for free. We also provide an Enterprise version which comes with a wide array of additional features. Development of the open source version is directly sponsored by Enterprise sales. If you like Phusion Passenger, or if you would like to use the Enterprise features, please consider buying one or more licenses. Thank you!

Beta 1 is just the beginning. We have more exciting changes planned for the near future! Curious? Enter your email address and name below and we’ll keep you up to date.



Roadmap Preview 3: resource control features

By Hongli Lai on July 30th, 2012

Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python 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 mid-2012, it aims to be the ultimate polyglot application server.

In Preview 1 and Preview 2 we introduced the upcoming Phusion Passenger Enterprise. This time we’ll uncover another few features.

Resource control

Web applicatons do not always behave correctly, whether it’s because of a bug in the web application or a problem in an external system such as the database. Phusion Passenger Enterprise provides the ability to limit various aspects of application processes’ resource usage.

Request time limiting

Phusion Passenger Enterprise can enforce a maxiumum time limit on a request. If the process is not done sending its response after that time, it is forcefully shut down with SIGKILL. This time limit can be configured on a per-request basis.

Memory usage limiting

Phusion Passenger Enterprise can enforce a maximum per-process memory usage. Unlike most memory limit enforcement tools, Phusion Passenger Enterprise measures memory usage by calculating the private dirty RSS. This is the best method to calculate the true memory usage of a process beacause it does not count shared memory.

Phusion Passenger Enterprise’s memory usage limiting is graceful. This means that it shuts down the process after it is done with all current requests, so that visitors do not get to see any errors.

Mechanisms such as vsize ulimit and rss ulimit are incorrect (they measure the wrong memory usage), buggy (rss ulimit does not work on Linux) or are not graceful (ulimit forcefully kills the process).

Stay tuned!

These resource control features make it extremely easy to keep your app processes in line with a flip of the switch. Furthermore, we’ve taken the opportunity to use non-traditional methods to measure memory usage and we try to impact visitors as least as possible even when enforcing resource limits.

The release is very soon now. We will be introducing an early bird pricing so be quick, because it won’t last forever. If you want to be among the first to grab an early bird license, fill in your email address below and we’ll keep you up to date!

Stay up to date with the latest Phusion news!



Roadmap Preview 2: live IRB console, deployment error resistance, new website

By Hongli Lai on July 26th, 2012

Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python web applications. It has a strong focus on ease of use, stability and performance; it 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 mid-2012, it aims to be the ultimate polyglot application server.

In the last Preview, we mentioned putting “final touches on the launch”, and some of you may wonder what these final touches are. Code-wise Phusion Passenger Enterprise is as good as done, so these final touches cover mostly the website. We believe that a good website, good documentation and good support resources are essential for any good product. Thus, in this Preview, we shall unveil another two Phusion Passenger Enterprise features. We shall also unveil a small preview of the new website.

Live IRB and debugging console

Don’t know what your application is doing? Phusion Passenger Enterprise provides two useful introspection and debugging features.

You can attach an IRB console to any live, running Ruby application process managed by Phusion Passenger Enterprise. In this console you can inspect the application’s state using Ruby code, and modify it in a REPL manner. Just invoke this command:

passenger-irb <PID OF THE APP>

Phusion Passenger Enterprise also allows you to attach a ruby-debug console to any Phusion Passenger-managed Ruby process that has the debugging flag turned on. Ruby-debug normally requires a terminal and assumes that there’s only 1 process, assumptions which are obviously not compatible with Phusion Passenger’s multiprocess model. We’ve patched ruby-debug (and the Ruby 1.9 equivalent, the debugger gem) so that they properly support debugging over TCP sockets. Phusion Passenger Enterprise’s ruby-debug integration thus relies on these patches. ruby-debug already ships the patch; debugger will ship the patch in the next release.

Use it as follows:

passenger-irb --debugger <PID OF THE APP>

The following screencast demonstrates its usage.

Deployment error resistance

In the event that an updated application fails to start (because of a configuration error, syntax error in the source code, or whatever), the open source version of Phusion Passenger will shut down all application processes and display an error. Phusion Passenger Enterprise offers deployment error resistance: when it encounters an error it will report the error to the logging system and “freeze” the process list. It will neither start any new processes, nor shut down any existing processes, until the administrator has signaled that the problem has been solved. This ensures that the web application stays up and running as long as possible.

New website

The greatest care has been put into the new website when it comes to aesthetics and usability. We want to make sure that we’re doing it right. Below you see the design for just the front page. We have many more designs besides this one.

What you see here is actually the third design iteration. Because as with most good things, the first try is often not successful. In a future Preview we’ll show you the other two designs. For 3 weeks we’ve worked day and night on our designs, in-house. When it came to implementing it, the entire Phusion team was deployed on this endeavor. The process has been super intensive but also extremely rewarding, especially when the team has such a good synergy.

Technical specs

It’s made in Adobe Photoshop and Adobe Illustrator. The frontpage Photoshop file consists of 231 layers and is grid aligned using 960.gs’s 24-column grid system. We intend on making the website fully responsive, but many of you are anxiously waiting for the product so we’ve decided to defer responsiveness to a later iteration of the website. We’ve also tried to create and keep as many elements as possible in a vector format so that they can be easily scaled later on. This is especially important as retina displays become more and more widespread.

The website is implemented in Rails 3.2, running on Ruby 1.9.3 and served by Phusion Passenger Enterprise 4.0 pre-beta. We’re not afraid to eat our dogfood so we run production websites on unreleased Phusion Passenger code. On the frontend front, we’re using HTML 5, CSS 3 and CSS 3 transitions. No Internet Explorer 6 support, I believe most readers are well aware of the reasons why. We also use webfonts whenever we can, but unfortunately not all font licenses allow this, so occasionally we have to render fonts to images. Needless to say, this latter is quite a pain and we hope more and more font foundries will consider webfont licensing in the future.

Stay tuned!

Roadmap Preview 3 will follow soon. We will unveil more Phusion Passenger Enterprise features.

You can easily stay up to date with our release progress! Just fill in your email address below and we’ll notify you.