The same info can be found here: http://www.mail-archive.com/[email protected]/msg00366.html
I'm using this setup in production now for about 2 weeks and it works very well! (Perlbal leaked too much memory). You do need nginx 0.6.27 or higher for this to work. It would be really nice if nginx would support this directly by simply acting on the X-Reproxy-URL content directly because there are issues with setting headers in the reproxy situation currently. It would also be cool if it supported multiple URL's and fallback if the first URL is not available (also a Perlbal feature) i.e. header["X-Reproxy-URL"] = "http://10.10.10.1/dev/fidfile,http://10.10.10.2/dev/fidfile" Gr, Andy On Thu, May 1, 2008 at 5:35 PM, mike <[EMAIL PROTECTED]> wrote: > On 5/1/08, Timo Ewalds <[EMAIL PROTECTED]> wrote: > > I agree, this is rather domain specific, and therefore not too useful. I > > propose instead to add a general purpose reproxy module to nginx, which > > would keep the domain specific url rewriting in your http/fcgi backend, but > > let nginx still do the webserving. Perlbal has this feature, and but I > don't > > think either lighttpd or nginx do. To be fair, lighttpd 1.5 sort of has it, > > though it needs to know about all the mogstore daemons ahead of time. The > > way perlbal (or squid) does it you just pass back a full url in a header, > > and it just does the request, making it much more flexible. Since > > lighttpd/nginx don't do this, our Ruby code is doing both the url > > translation and the request to the mogstored, which is much less efficient > > than Ruby just did the url translation and let lighttpd/nginx do the > > mogstore proxying. > > The rationale for this is hoping to skip having to go into > PHP/Perl/application level code. > > I believe nginx can already do it today, if you involve a PHP level > script to determine the storage node(s) to try, and then tell nginx to > grab it from there... > > I found a site[1] in Japanese that from what I can tell has determined > how to do it. But to be able to skip needing any PHP level code would > be great; it would allow the webserver to use MogileFS as a pseudo > filesystem for a large majority of most websites' files (well, those > that have user generated data) - or I guess *any* assets. > > 1. http://d.hatena.ne.jp/perezvon/20080418/1208531594 >
