[Server-devel] Reverse proxies on the XS (was: Re: Everex gpc mini - an option for the XS?)

[Martin Langhoff]

On Fri, Mar 7, 2008 at 8:42 AM, Ivan Krstić
<krstic at solarsail.hcs.harvard.edu> wrote:
> On Mar 6, 2008, at 7:58 PM, Sameer Verma wrote:
>  > I'd imagine Varnish would help with speeding things up on the Moodle
>  > side. Is this correct?
>
>  It's an insufficiently specific question:

>  * For making sure pages previously visited within a session by the
>    same logged-in user do not require network retransmission, web
>    applications should issue HTTP-standard expiration dates and
>    validator headers. Standards-compliant browsers will obey these
>    without the need for a reverse proxy to sit in front of Apache.

Yes and no. There are enough web apps out there with weird caching
bugs that I am sure brosers misbehave plenty just to survive "in the
real world". To an extent, we can tell the browse activity to assume
that the caching headers coming from the XS make sense - if the gecko
engine has suck knob...

>  * If the web application has expensive-to-generate pages whose
>    contents do not vary often or by user but are regenerated on each
>    hit, it's doing something wrong. Putting a reverse proxy in front
>    of it will mask the brokenness, but the behavior is still broken
>    and the web application should fix it.

Yes, and to an extent I know that moodle and mediawiki are mostly ok.
Emphasis on the mostly - some things are hard to do right, and in some
cases, not worthwhile because webbrowsers and buggy proxies ignore
your correctly-crafted headers.

>  * If the web application has expensive-to-generate pages that do vary
>    by user (e.g. have an indication of which user is logged in or any
>    other per-user customization), a reverse proxy won't help unless
>    the application emits ESI markup and the revproxy obeys it. I bet
>    Moodle doesn't, and virtually none of the small proxies support ESI
>    anyway. Varnish has partial support that's not production-quality.

Nice - I didn't know about ESI. Interesting thought.

There is a whole another reason why a cheap rev proxy will be handy in
the XS (and in most webapp scenarios) -- normally the webapp process
is enormously expensive in terms of RAM. Things like the odd apache
memory model exacerbate the problem, but even without apache's
oddities, all the scripting languages are memory hogs and webapp
programmers are traditionally too cushioned to realise that their
programing style makes this worse. (I've done a lot of work to make
moodle core smarter and more maintainable in that regard, we'll see
how things go with it and other webapps we'll ship. There is a lot of
developer education we need to do there, just like with efficient
techniques for sugarised apps...)

Going back to the memory-heave processes -- if the process can produce
the output quickly but the clients are potentially slow it makes a lot
of sense to offload the serving of bytes to a small-mem-footprint
process, and keep less apache/php processes around and very busy.

Having said that, if we have squid or some other flexible proxy, we'll
probably use it for both purposes.

cheers,



martin