Thanks,
I will probably do that next. I am not clear what the difference is
between running squid and doing a mod_proxy, in the case of all dynamic
content... a remark in the tuning guide that i saw back in June was vague about
this, saying it wasnt clear whether squid can cache larger doucments or
if there is some limit.
I did read the guide, although I didnt re-read it enough, as Vivek
so very gently pointed out to me. I think that there needs to be an
intro that says, basically, if you expect more than N requests per
minute for dynamic content, then start from this config, and the rest
of the tuning guide is all about tweaking that.
Or it could just be that received wisdom never makes the imprint
that real mistakes made do..
-Justin
On Fri, Oct 29, 1999 at 12:04:26PM -0500, Leslie Mikesell wrote:
> According to [EMAIL PROTECTED]:
> >
> > I still have resisted the squid layer (dumb
> > stubbornness I think), and instead got myself another IP address on the
> > same interface card, bound the smallest most light weight separate
> > apache to it that I could make, and prefixed all image requests with
> > http://1.2.3.4/.. voila. that was the single biggest jump in throughput
> > that I discovered.
>
> You still have another easy jump, using either squid or the two-apache
> approach. Include mod_proxy and mod_rewrite in your lightweight
> front end, and use something like:
> RewriteRule ^/images/(.*)$ - [L]
> to make the front-end deliver static files directly, and
> at the end:
> RewriteRule ^(.*)$ http://127.0.0.0:8080$1 [p]
> to pass the rest to your mod_perl httpd, moved to port 8080.
> If possible with your content turn off authentication in
> the front end server.
>
> >.. people were connecting to the site via this link, and packet loss
> > was such that retransmits and tcp stalls were keeping httpd heavies
> > around for much longer than normal..
>
> Note that with a proxy, this only keeps a lightweight httpd tied up,
> assuming the page is small enough to fit in the buffers. If you
> are a busy internet site you always have some slow clients. This
> is a difficult thing to simulate in benchmark testing, though.
>
> > comments or corrections most welcome.. i freely admit to not having
> > enough time to read the archives of this group before posting.
>
> I probably won't be the only one to mention this, but you might have
> a lot more time if you had, or at least gone through the guide
> at http://perl.apache.org/guide/ which covers most of the problems.
>
> Les Mikesell
> [EMAIL PROTECTED]
