I looked at mod_proxy and found the pass thru buffer size
is IOBUFSIZ, it reads that from the remote server then
writes to the client, in a loop.
Squid has 16K.
Neither is enough.
In an effort to get those mod_perl daemons to free up for long
requests, it is possible to patch mod_proxy to read as much as
you like in one gulp then write it..
Having done that, I am now pretty happy - mod_rewrite mod_proxy
mod_forwarded_for in front of modperl works great.. just a handful
of mod_perls can drive scores of slow readers! I think that is better
than squid for those with this particular problem.
-Justin
On Mon, Jan 17, 2000 at 07:56:33AM -0800, Ask Bjoern Hansen wrote:
> On Sun, 16 Jan 2000, DeWitt Clinton wrote:
>
> [...]
> > On that topic, is there an alternative to squid? We are using it
> > exclusively as an accelerator, and don't need 90% of it's admittedly
> > impressive functionality. Is there anything designed exclusively for this
> > purpose?
>
> At ValueClick we can't use the caching for obvious reasons so we're using
> a bunch of apache/mod_proxy processes in front of the apache/mod_perl
> processes to save memory.
>
> Even with our average <1KB per request we can keep hundreds of mod_proxy
> childs busy with very few active mod_perl childs.
>
>
> - ask
>
> --
> ask bjoern hansen - <http://www.netcetera.dk/~ask/>
> more than 60M impressions per day, <http://valueclick.com>
