On Mon, 30 Oct 2000, Tim Sweetman wrote:
> Matt Sergeant wrote:
> >
> > On Fri, 27 Oct 2000, Tim Sweetman wrote:
> >
> > > In no particular order, and splitting hairs some of the time...
> > >
> > > Sounded like mod_backhand was best used NOT in the same Apache as a phat
> > > application server (eg. mod_perl), because you don't want memory-heavy
> > > processes sitting waiting for responses. You'd be better off with a
> > > separate switching machine - or serve your static content from
> > > machine(s) that know to backhand dynamic requests to a phat machine. I
> > > think that's what Theo reckoned...
> >
> > Yes, but the backend mod_perl servers are running backhand. So you have:
> >
> > B B B B
> > \ | | /
> > \ \/ /
> > \|/
> > F
> >
> > Where all the servers are running mod_backhand, but only F is publically
> > accessible. There may also be >1 F. Its in his slides, and is prettier
> > than the above :-)
>
> Yeah. I know how it was set up in Theo's demo (like that) but I got the
> impression that this wouldn't be optimal for a mod_Perl setup (or other
> big-footprinted configuration). You _can_ run mod_backhand on your
> content servers. You don't _have_ to.
Here's what I recall Theo saying (relative to mod_perl):
- Don't use a proxy server for doling out bytes to slow clients; just set
the buffer on your sockets high enough to allow the server to dump the
page and move on. This has been discussed here before, notably in this
post:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/grerdbrerdwul/[EMAIL PROTECTED]
The conclusion was that you could end up paying dearly for the lingeirng
close on the socket.
- If you use apache+mod_proxy as a load balancer in front of your back-end
servers (as opposed to a commercial solution like big ip), use
mod_backhand instead and your front-end server will be able to handle
requests itself when it's not too busy.
- He has created a way for proxied requests to use keep-alive without
enabling keep-alive for the whole server. The obvious problem - that each
server will soon use up every other server's available clients - is
somehow avoided by sharing open sockets to the other servers in some
external daemon. This sounded cool, but fishy.
Ultimately, I don't see any way around the fact that proxying from one
server to another ties up two processes for that time rather than one, so
if your bottleneck is the number of processes you can run before running
out of RAM, this is not a good approach. If your bottleneck is CPU or
disk access, then it might be useful. I guess that means this is not so
hot for the folks who are mostly bottlenecked by an RDBMS, but might be
good for XML'ers running CPU hungry transformations. (Yes, I saw Matt's
talk on AxKit's cache...)
> One thing I have my eye on (which doesn't mean I'll necessarily get it
> done :) ) is some sort of data-holding-class that sits between an
> application and a template in a transparent way (eg. it could hold the
> method names & args that you were passing to a templating system, like a
> "command" design pattern IIRC).
In Perl, we call that a "variable". (Sorry, couldn't resist...)
Templating systems in Java jump through hoops to make generic data
structures, but Perl doesn't have to. Just freeze it with Storable if you
need to save it.
> This would potentially allow:
> + switching between different templating systems ...?
Nearly all of them use standard perl hash refs.
> + checking out template tweaks without rerunning the app - good for
> "interactive" systems which
> keep chucking form data at users
This is easy to do with most systems. I once wrote something that could
turn arbitrary form inputs into a data structure suitable for feeding to
Template Toolkit or similar. Then I could create a form for entering
different kinds of test data, and save the test data using Storable. It
was used for building templates for a system which ran the templating as a
batch process and so had a terrible turnaround time for testing changes.
> + (fairly transparent) conversion to XML/XSL/etc at an appropriate time,
> as/when/if a site/project
> grows to an appropriate size
There are some modules out there that serialize perl data structures as
XML. Or you can just write a template for it.
- Perrin
