Passenger (mod_rails) released | Hacker News Reader

Passenger (mod_rails) released

modrails.com

33 pointszapnap24 comments

Setting up apache proxy + mongrels, while not impossible, is also not brain-dead easy.

Also, in virtual private server scenarios RAM may be a hot commodity (slicehost, for instance) -- so in theory this should help you run more rails sites with less RAM, since you won't have to spin up individual mongrel clusters for each domain.

Here's the root link to mod_rails website: http://www.modrails.com/

1. What's with the rails community's obsession with naming things names related to trains? What's wrong with "mod_rails"?

2. "touch tmp/restart.txt" seems like an odd way to signal a restart of your app... what's the reason behind this?

for web hosting providers only giving ftp/sftp access, there's really no other way to signal a restart than to upload another file. you have no control over the processes and using some web-based administration too complex.

Just noticed that the "Passenger blog":http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-pa... mentions that Dreamhost has been beta testing Passenger. If thats true, and Dreamhost rolls it out (soon!), then Rails is going to become as ubiquitous as PHP for hobby-coders that don't enjoy playing sysadmins. I'm probably one of them.

And if you want to do the same-ish thing with similarly little configuration (indeed, less) with any framework (not just Rails) or even with a non-Ruby language, check out SwitchPipe: http://switchpipe.org/

The answer to this is probably obvious, but, can someone sell my on why I want mod_rails? What's wrong with the tag-team app server / web server architecture?

You're probably not the target audience. It's meant to ease deployment so it's more like PHP in a LAMP setup.

In the author's words (http://www.modrails.com), here are the main features:

- Deployment is only a matter of uploading application files. No Ruby on Rails-specific server configuration required!

- Built on the industry standard Apache web server.

- Allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition (optional).

- Zero maintenance. No port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible.

- Designed for performance, stability and security. Passenger should never crash Apache even in case of crashing Rails applications.

- Well-documented, for both system administrators and developers!

Not everyone wants to manage both a front-end server and six little mongrels running around just to run an app.

This is great news good to see it!

What I have been wondering is what happens to the memory footprint? It says somewhere on the site it is reduced by 33% - is that a typical reduction?

Also, if this is like mod_perl, deployment wasn't really as simple as it seemed. The general advice on mod_perl was to proxy requests from your front end 'static' webserver to the mod_perl one, because each apache process had to effectively run a Perl interpreter, giving them a big memory footprint. You don't want to use your expensive mod_perl/ruby processes to serve images etc.

I also think there are other advantages to running expensive processes behind a proxy (I may be wrong on this one), but I think that slow clients tend to tied up the front end process as it streams the data to them.

If you have appServer -> proxy -> slow client, the app server sends the data to the proxy at LAN speed, freeing it to serve another request, and the proxy ties up a process streaming the data to the client.

I am not trying to criticize, I am interested in whether they solved these problems (if they even are problems anymore) and how.

this is huge, although i think this needed to come out earlier. rails deployment has already been generally pegged as 'hard' or a 'pain'. I have gotten use to getting a rails app coded fast then getting ready to spend some time deploying.

Do note that this is not the first attempt at this, however it looks. My own system (I say "my" loosely, it's public domain and open source) SwitchPipe: http://switchpipe.org/ is already in widespread usage, but its focus is a little different.

That is why i said it seems a little late. I remember stabbing my eyes out when i first got into rails once i tried deploying stuff, back in the fastcgi/lighttpd days.

btw, switchpipe is going to rule the world in a few months, the support for all the other frameworks looks awesome.

To be fair, fastcgi wasn't /too/ bad IF you actually had it running well at least once g and that varied incredibly from machine to machine, alas. It did use a similar underlying mechanism to most of these other alternatives, just in a rather messy way.

I don't think SwitchPipe will rule anything, but perhaps once it's up on Github (instead of SVN) and I release the next version, more baby steps can be made. I'd love to make it even more simple somehow, and perhaps port it to a much faster base (probably Python).

fair enough :)

Yeah, I've had good luck with mod_fcgid, actually. I don't have that much traffic, but I like the fact that the software takes care of setting up and tearing down new instances of the application server, rather than having to take a wild guess at how many mongrel instances might be needed per virtual host. This is something that mod_rails also promises to do well.

What would be the main advantages switchpipe has over the conventional mod_rewrite solution under Apache?

I assume you mean over using mod_rewrite to do proxying direct to backend app servers?

If so: - SwitchPipe controls backend app server processes. If an app isn't being used, it doesn't need to be running. - If an app is under heavy demand, I want more instances (up to a limit) to be launched to deal with it. - SwitchPipe deals with all of the port numbers. No port numbers to deal with as a user.

Just some minor points, but with big usability gains.

Article links to screencast. gem install passenger should pull down passenger-1.0.1. taking a look...

Reply on news.ycombinator.com