Vivek Khera <[EMAIL PROTECTED]> writes:
> Squid does indeed cache and buffer the output like you describe. I
> don't know if Apache does so, but in practice, it has not been an
> issue for my site, which is quite busy (about 700k pages per month).
>
> 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).
1) Netscape/IE won't intermix slow dynamic requests with fast static requests
on the same keep-alive connection
2) static images won't be delayed when the proxy gets bogged down waiting on
the backend dynamic server.
Both of these result in a very slow user experience if the dynamic content
server gets at all slow -- even out of proportion to the slowdown.
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.
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.
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.
--
greg
