What's new in Passenger 5 part 2: better logging, better restarting, better WebSockets and more

We're happy to announce version 5.0.1 of the Phusion Passenger application server for Ruby, Python and Node.js. Version 5.0.1 is officially ready for production.

The 5.x series is also unofficially known under the codename "Raptor", and introduces many major improvements such as:

  • Much better performance
  • A new HTTP JSON API for better insights into server and application behavior
  • Better logging
  • Better WebSocket support

This is part 2 of a two-part blog post which describes the main changes in Passenger 5. See also part 1: performance and HTTP JSON API.

To learn how to upgrade to Passenger 5, please refer to the release notes.

Better logging

We've made the log levels in Passenger 5 much more fine-grained. This makes it easier for administrators to obtain more information from Passenger without being overwhelmed by low-level debugging information that is only useful to Passenger developers.

Passenger 5 has seven log levels:

  • 0 crit: Show only critical errors that would cause Passenger to abort.
  • 1 error: Also show non-critical errors -- errors that do not cause Passenger to abort.
  • 2 warn: Also show warnings. These are not errors, and Passenger continues to operate correctly, but they might be an indication that something is wrong with the system.
  • 3 notice: Also show important informational messages. These give you a high-level overview of what Passenger is doing.
  • 4 info: Also show less important informational messages. These messages show more details about what Phusion Passenger is doing. They're high-level enough to be readable by users.
  • 5-7 debug: Debugging information, only useful to Passenger developers.

Better log rotation support

Passenger 5 also has better support for log rotation. In earlier versions, if you log rotate the Nginx/Apache log file, then any further Passenger log messages are lost, because there was no way to tell Passenger to reopen the log file. You had to fully restart Nginx/Apache, which also restarts all apps.

In Passenger 5, you can use the passenger-config reopen-logs command to tell Passenger to reopen its log file. Run the following command to learn more:

passenger-config reopen-logs --help

Improved application restarting mechanism

In Passenger 4 and earlier, the main way to restart an app was by touching tmp/restart.txt. This mechanism was invented in order to accomodate shared hosts that didn't provide SSH access. But checking restart.txt for every request has proven to be a performance bottleneck.

In Passenger 5, the main mechanism to restart an app is by running the passenger-config restart-app command. Running the command will show you a menu in which you can choose which app to restart. You can even use this tool non-interactively: just pass --help to learn how.

Improved process termination mechanism

If you wish to terminate a specific application process -- maybe because it's misbehaving -- then you can do that simply by killing it with the kill command. Unfortunately this method has a few drawbacks:

  • Any requests which the process was handling will be forcefully aborted, causing error responses to be returned to the clients.
  • For a short amount of time, new requests may be routed to that process. These requests will receive error responses.

In Passenger 5 we've introduced a new, graceful mechanism for terminating application processes: passenger-config detach-process. This command removes the process from the load balancing list, drains all existing requests, then terminates it cleanly.

You can learn more about this tool by running:

passenger-config detach-process --help

Improved WebSocket support

Passenger 5 has much better support for WebSockets. WebSockets also worked in version 4, but there were minor issues. Most notably, if you tried to restart an application process then Passenger 4 would wait until all WebSocket connections are closed -- either by the server or by the client -- before actually restarting the app. Thus, a restart could take an indefinite amount of time to complete.

In Passenger 5, WebSocket connections are aborted when you initiate an application restart. Furthermore, passenger-status --show=requests now prints much more detailed information about the state of WebSocket connections.

You can see our WebSocket support in action through the following demos:

Rails < 2.3 support dropped

We've dropped support for Ruby on Rails 1.x, 2.0, 2.1 and 2.2. This is because the code was getting in the way of our performance optimizations. The minimum Rails version that we now support is 2.3, but a config.ru file is required. Please read the upgrade notes regarding Rails 2.3 support.

Please note that Ruby version support hasn't changed. The minimum Ruby version that we support is 1.8.5.

Passenger Enterprise updated

Phusion Passenger also has an Enterprise version which comes with a wide array of additional features such as zero-downtime restarts, multithreading, better debugging support, etc.

Passenger Enterprise has been updated as well. All the changes mentioned in this article are also available in the Enterprise version.

By buying Phusion Passenger Enterprise you will directly sponsor the development of the open source version.

Learn more about Passenger Enterprise »

Conclusion

This is part 2 of a two-part blog post which describes the main changes in Passenger 5. See also part 1: performance and HTTP JSON API.

To learn how to upgrade to Passenger 5, please refer to the release notes.

[img

Union Station is Phusion's brand new take on Passenger application monitoring and analytics. Union Station aims to help you easily find performance bottlenecks and errors in your application and to help you fix them. Sign up for a free 1 month trial today!

comments powered by Disqus