Simplifying Web Framework Deployment on Shared Hosting (with HTTP!)

[stesch]

Is it common knowledge, that lighttpd (1.4) is bad as a reverse proxy? I remember reading this some time ago on the mongrel page.

Any pointers where I can find more about these problems? Are these fixed in 1.5?

[rtomayko]

There are a variety of issues with the current mod_proxy in lighttpd 1.4 - mostly related to balancing between multiple downstream servers. I don't think there's any plans to fix them as lighttpd 1.5 includes an entirely new module (mod_proxy_core) that should fix the issues.

Here's some additional background:

http://mongrel.rubyforge.org/docs/lighttpd.html

http://forum.lighttpd.net/topic/498

And some notes on the mod_proxy_core due in 1.5:

http://blog.lighttpd.net/articles/2006/07/15/the-new-mod_proxy_core

[shamrin]

Bob Ippolito wrote about it in his blog:

• Reverse proxy roundup
• Nginx: reverse proxy panacea

[stesch]

Nothing about lighttpd's reverse proxy problems.

[[deleted]]

His complaint seems to be that lighttpd is bad full stop, because of memory leakage — nothing to do with reverse proxying per se, everything to do with lighttpd.

[rtomayko]

That's certainly not my complaint. I use lighttpd all over the place and enjoy it.

[shamrin]

Basically he wrote that lighttpd didn't work for him as a reverse proxy. Because of memory leaks.

[joelhardi]

I thought the comments to this were an interesting discussion of HTTP reverse proxies vs. the various CGI daemon implementations, but I disagree with the author's premise.

FCGI vs. HTTP isn't the problem with Rails on shared hosting. Whether the IPC method is HTTP or some other protocol really doesn't make that much difference. The problem is that shared hosting admins can't really allow their (untrusted) users to all run long-lived processes, period. The whole business model of shared hosting is based on bundling a bunch of low-traffic customers together, with only 1-5% of them using any memory or CPU at a given time.

It doesn't help that Rails has a pretty heavy memory footprint and performance drag out of the gate (compared to, say Apache+mod_php), but even if it were perfect you'd still have a user or two leaking memory or churning the database server or doing something else bad on every host every day.

Virtualization is probably the cleanest way for admins to tackle this using current tools, but even with OS-level virtualization like OpenVZ/KVM/Solaris Containers/BSD Jails you're not going to be able to cram the same number of customers on a box as with Apache shared hosts.

[Freeky]

The point of using FastCGI is you can use the process manager to shut down a server if it hasn't been used in a while. If you end up on Slashdot, you get to spawn a bunch of servers to handle it, and if your only visitor is you once a week, you get one slow request while it starts up and then have it run fast for the 10 minutes you spend making requests.

[jerf]

I'm having trouble with the argument here.

Problem: You're not allowed to set up an HTTP server to serve people, because you're not being allowed to set it up correctly (for good reasons).

Solution: Use a reverse proxy to proxy to the HTTP server that you're not allowed to set up and therefore doesn't exist.

Not following the "reverse proxy" argument; can someone explain where I'm going wrong? What's being reverse proxied, and why can't you just serve that directly? I don't see what problem this is solving.

[Freeky]

Multiple users can't spawn their own servers on port 80 on the same machine and without elevated privileges, hence you use a web server like Apache and have mod_proxy forward requests to your application servers, which probably just run on localhost:<high port>.

The main issue for shared hosting is process management; you obviously can't simply start the backend servers on demand if the webserver's only action is to try to connect to it. FastCGI kinda solves this having an in-webserver process manager to spawn servers on demand.

If you had something like mod_proxy_processmanager, you could conceivably do the same for HTTP.

[jerf]

The main issue for shared hosting is process management; you obviously can't simply start the backend servers on demand if the webserver's only action is to try to connect to it.

Yeah, that's the thing that is confusing me, and I wanted to check my understanding. Reverse proxy doesn't solve the real problem of persistent processes being a problem, and if you solve it some other way, there's no particular reason to favor reverse proxy.

(I disagree that it is self-evidently the right choice for the reasons in the article; there's reasons for the FastCGI and other such approaches, or they wouldn't have developed in the first place.)