Re: Seeking enterprise ideas for Squid

Wojciech Puchar wrote:
>>>
>>>look at russian oops proxy...
>>>
>>>
>>>they already did it. and it really works fast.
>>
>>Not as fast as Squid. Not even close on big hardware.
>>
>
>
> on linux - yes.

I can't argue too strongly about that, as my experience tuning FreeBSD
is weaker than with tuning Linux. But in my tests, Oops was also slower
than Squid on FreeBSD, though by a smaller margin. This could also be
partially due to inexperience with Oops, as I obviously have more
experience tuning Squid than Oops. I did overcome all of the common
arguments for why Linux is a poor platform for running Oops (i.e. it is
easy to allow Oops to use 'enough' threads under kernel 2.4, though it
requires a source change in Oops and some tuning at the OS level), and
was able to seemingly max out other parts of the system. The DB layer
is what I suspect is the limiting factor. GigaBase would never run
stable at high loads, so BerkeleyDB was the only choice on both platforms.

But I doubt one could double or triple the performance of Oops just by
making GigaBase work reliably or making a few more OS tweaks in FreeBSD,
and that's what it would take to match Squid's performance on multi-disk
machines.

On machines with small memory and a single disk, however, Oops is
comparable to Squid...probably even superior since it doesn't require as
much memory for serving a small number of clients from a reasonable
sized cache disk.

-- 
Joe Cooper <joe@swelltech.com>
Web caching appliances and support.
http://www.swelltech.com