Re: Accelerator mode: connect retry possible?

>>>>> On Mon, 19 Apr 1999 11:07:46 +0200, Henrik Nordstrom <hno@hem.passagen.se> said:

> Andreas J. Koenig wrote:
>>
>> >>>>> On Mon, 19 Apr 1999 00:38:56 +0200, Henrik Nordstrom <hno@hem.passagen.se> said:
>>
>> > Sounds like you are accelerating a Apache HTTP server on the same
>> > machine as Squid, which is in my opinion not a very great thing to do.
>> > Frankly you are most likely better off not "accelerating" that server
>> > with Squid.
>>
>> Yes, squid is on the same server. In a mod_perl environment this seems
>> pretty much like a win (compared to no accelerator at all).

> Agreed. I didn't know you were using mod_perl.

That's very good to hear! Thank you for your quick response!

>> And now that. Would you mind giving me a few hints why you say so and
>> what you would recommend instead? If we must stop people from falling
>> into a trap, we must do it now. Thanks for your help!

> Ok. A short list of things which makes Squid a poor accelerator:

> * Speed. Squid is not very fast today when compared to plain file based
> web servers available. Only if you are using a lot of dynamic features
> such as mod_perl or similar speed is a reason to use Squid, and then
> only if the application and server is designed with caching in mind.
> * Memory usage. Squid uses quite a bit of memory.
> * HTTP protocol level. Squid is pretty much a HTTP/1.0 server, which
> seriously limits the deployment of HTTP/1.1 features.
> * HTTP headers / dates, freshness. Your server will be giving out "old"
> pages, which might confuse downsteam/client caches. Also chances are
> that you will be giving out stale pages.
> * Stability. Compared to plain web servers Squid is not the most stable.
> Can't tell how the situation is when you are using mod_perl however.
> * Probably a couple of more things.

OK, these are all the things I'm aware of and can live with. I'm glad
these are the things you had in mind.

Another one would be that squid doesn't delay POST requests which
would be the ideal counterpart to taking over outgoing traffic.

> Reasons to run Squid as a accelerator:
> * Speed. If your web server is very slow then Squid migth help.
> * Memory usage, if the web server uses astronomical amounts of memory.
> * Non-linear URL space / server setup. You can use Squid to play some
> tricks with the URL space and/or domain based virtual server support.

One reason more we usually consider is for serving slow connections.
If a part of the user base is connected over slow links, squid frees
the apache process quickly and patiently delivers the response.

> My recommendations for a mod_perl Apache server is: (but I am sure you
> already know these, and my experience of mod_perl is limited so I can't
> tell how effective this is)
> * Preload all used modules in the main server.

Yupp.

> * Configure the system to assign swap space on demand rather than on
> allocation if possible (very few systems supports this).
> * If the above swap arrangement is not possible then add astronomical
> amounts of swap space. If mod_perl is properly configured huge amounts
> of swap will be reserved but not very much of it actually used.

Interesting idea. Currently I just do no swapping at all and leave
about 120MB for kernel cache and buffers. But I can see scenarios
where this recommendation is very valuable. Thanks!

Regards,

-- 
andreas