Recommended reading material
- Users guide
-
The users guide, also included in the Passenger gem and source tarball,
describes among other things:
- Installation prerequisites
- Configuration
- Solutions for troubleshooting
- Wiki
- Our publicly editable Wiki allows users to contribute useful documentation and other information.
- Developer documentation
- We’ve written extensive developer documentation so any anyone may contribute to Passenger or peer-review our code. Please check the Development page.
Frequently Asked Questions (or Frequently Given Answers)
- It seems to leak memory like mad during startup. What's going on?
-
What you're seeing is probably not a memory leak, but the effects of your stack size configuration. We've seen this problem before with one of our beta testers. What happens is that Apache's "Virtual Memory" size (VSZ), as reported by 'ps' or 'top', jumps to an unusually high number.
Please type 'ulimit -a' to check your stack size. Use 'ulimit -s some_number' to change your stack size. A stack size of 2 MB should be enough for Passenger. The stack size should be no more than 8 MB.
- I can’t install it / I’m having problems after installation
- Please read the troubleshooting section of the Users Guide. If that doesn't help, please go to the Support page.
- How is performance?
-
According to our tests, Passenger is a bit faster than Mongrel, and seems to be on par with Thin:
Independent performance benchmarks have shown similar results:
- diffuse.it (Passenger is shown to be faster than Mongrel)
- Arie's blog (Passenger is shown to be as fast as Mongrel)
Though we have to say that absolute speed is not our goal. Our primary goals are ease of use, low maintenance and high stability. Of course, we do strive for sufficient performance, and we think that Passenger is sufficiently fast.
- Does it support other Ruby frameworks (Merb, Camping, etc.)?
- No.
- What?! Why??
-
Because this is an evil plot created by evil overlords, with
the goal of
world dominationdestroying all other Ruby frameworks. - …
-
Actually…
There is the following saying: Jack of all trades, master of none. Our intention is to be masters, not Jacks. The primary goal of version 1.0 was to create an easy-to-use, low-maintenance, stable and fast Ruby on Rails deployment system for Apache. And we've put a lot of effort into reaching that goal. Implementing support for other Ruby frameworks would have deviated us from that goal and would have increased development time significantly.
That said, nothing prevents future versions from supporting other Ruby frameworks, or from becoming a generic Ruby web application deployment platform. Please discuss it with us if you're interested in steering development towards that direction.
- Why not mod_ruby?
-
- For one, look at its website. Last release was from 2006. We’re not sure whether it’s still maintained anymore.
- Nobody (or almost nobody) uses it in production. This fact alone says a lot.
-
The Rails wiki
page for mod_ruby lists a pretty bad limitation:
“mod_ruby uses a shared interpreter per Apache process, which means that multiple Rails applications on the same Apache setup with mod_ruby would share the framework classes. This doesn't work well with the Rails model of using class-level configuration attributes, so it’s considered unsafe to use mod_ruby and Rails with more than one application running per Apache setup, because different applications may start sharing the classes.”
- Is it stable?
-
We’ve done a lot of stress testing. So far we’ve been unable to make Passenger crash, even when under high load (e.g. ab -n 10000 -c 100).
Also, we've performed some robustness tests as well, and you can read our findings here.
The codebase has also been extensively tested with tools such as Valgrind in order to ensure that there are no memory corruption bugs.
- What happens if a single Rails app crashes? Will it take Apache down as well?
- If a single Rails app crashes, Apache is completely unaffected. Said Rails application will be restarted next time its domain is accessed, as if nothing ever happened. Of course, the error will be logged so that a system administrator or developer can figure out what went wrong.
- Does it support page caching? Are static assets accelerated?
-
Page caching is fully supported, without the need to configure mod_rewrite.
Static assets are accelerated, i.e. they are served directly by Apache and do not go through the Rails stack. This of course implies that page caching is accelerated as well.