According to Greg Stark:
> > I think if you can avoid hitting a mod_perl server for the images,
> > you've won more than half the battle, especially on a graphically
> > intensive site.
>
> I've learned the hard way that a proxy does not completely replace the need to
> put images and other other static components on a separate server. There are
> two reasons that you really really want to be serving images from another
> server (possibly running on the same machine of course).
I agree that it is correct to serve images from a lightweight server
but I don't quite understand how these points relate. A proxy should
avoid the need to hit the backend server for static content if the
cache copy is current unless the user hits the reload button and
the browser sends the request with 'pragma: no-cache'.
> 1) Netscape/IE won't intermix slow dynamic requests with fast static requests
> on the same keep-alive connection
I thought they just opened several connections in parallel without regard
for the type of content.
> 2) static images won't be delayed when the proxy gets bogged down waiting on
> the backend dynamic server.
Is this under NT where mod_perl is single threaded? Serving a new request
should not have any relationship to delays handling other requests on
unix unless you have hit your child process limit.
> Eg, if the dynamic content generation becomes slow enough to cause a 2s
> backlog of connections for dynamic content, then a proxy will not protect the
> static images from that delay. Netscape or IE may queue those requests after
> another dynamic content request, and even if they don't the proxy server will
> eventually have every slot taken up waiting on the dynamic server.
A proxy that already has the cached image should deliver it with no
delay, and a request back to the same server should be serviced
immediately anyway.
> So *every* image on the page will have another 2s latency, instead of just a
> 2s latency for the entire page. This is worst in Netscape of course course
> where the page can't draw until all the images sizes are known.
Putting the sizes in the IMG SRC tag is a good idea anyway.
> This doesn't mean having a proxy is a bad idea. But it doesn't replace putting
> your images on pics.mydomain.foo even if that resolves to the same address and
> run a separate apache instance for them.
This is a good idea because it is easy to move to a different machine
if the load makes it necessary. However, a simple approach is to
use a non-mod_perl apache as a non-caching proxy front end for the
dynamic content and let it deliver the static pages directly. A
short stack of RewriteRules can arrange this if you use the
[L] or [PT] flags on the matches you want the front end to serve
and the [P] flag on the matches to proxy.
Les Mikesell
[EMAIL PROTECTED]
