Re: [squid-users] Configuring Squid v2.4 for GDSF and LFUDA replacement policies

Gino LV. Ledesma wrote:

> On Wed, Feb 13, 2002 at 02:14:25AM -0600, Joe Cooper wrote:
>
>>I believe all you need to get the heap replacement policies in any
>>recent version of Squid is:
>>
>>--enable-removal-policies="heap,lru"
>>
>
> Thanks for the clarification. I was wondering why I had two extra
> directories upon checking the directories.
>
> So then I guess its simply specifying heap GDFS or heap LFUDA in the
> squid.conf file?

Correct.
 
>>Contrary to what you've read, the results of using the heap policies is
>>rather minimal. In low storage environments, the difference may be
>>worth noting, but in modern machines with hard disks way too big for web
>>caching purposes already, any one of the policies will provide nearly
>>ideal hit ratio. There is probably a small amount of benefit to using
>>GDSF for memory replacement, because space is at such a premium and the
>>more popular smaller objects are really best served from RAM. I've only
>> done a few benchmarks of the impact of GDSF for memory replacement,
>>and the impact is small enough to where I don't have any firm
>>conclusions to draw about it--but it probably makes good sense in the
>>real world.
>>
>
> I am quite interested in doing benchmarking. We have a rather heavily
> used proxy that's serving at least 80-100 heavy/demanding users at any given time. Currently, I've been told that the proxies are configured using the default (stock) options for v2.2.
>
> Aside from trying to use async-io/DISKD under GNU/Linux (which my friend
> says was quite unstable/unreliable last time he used it), I've been
> looking at lru, heap lru, etc as well. We're trying to do some
> fine-tuning with squid to better improve the performance as it is.
 

Squid 2.3 was never very solid with aufs. aufs in 2.4 is pretty good.
DiskD has rarely had any problems since it went into 2.4, and is quite
solid to this day. aufs is more complicated, and does still have a few
quirks in all versions, but is certainly stable enough for production
deployment in most environments. Switching to diskd or aufs will be the
single biggest thing you can do to improve Squid's overall throughput
(latency under low loads may actually go up by a tiny amount though).

 
>>So, to put it in other terms: the additional replacement policies are a
>>neat idea, and fun to poke at, but for most users they aren't going to
>>really change the way Squid behaves either in hit ratio or in
>>performance. (If you have a small hard disk, or a lot of memory to play
>>with GDSF you're probably one of the users it will help.)
>>
>
> I'm not sure how much is a "lot", but one of the proxies we intend to
> deploy has 512MB of RAM, whereas the others have 128MB. Hard Disk space
> is a bit plentiful.
>
> I guess I'll turn to other fine tuning articles once more. I've still to
> read up on cache_mem and cache_dir tweaks.

Enable DiskD and don't worry so much about the micro-tunings that can be
achieved with tweaks cache_mem (a little effective if you raise it to 16
or 32MB, for example) and cache_dir (almost entirely ineffective--you'll
probably make things worse).

The two async disk options, aufs and diskd, are the most significant
performance enhancements Squid has had in years and are well worth using
if you need additional performance. I've found through a couple hundred
benchmarks that most other options in Squid have a minimal impact on
performance, if any, and often already have quite reasonable
defaults--changing them sometimes leads to degradation rather than
improvement. I'm assuming here, of course, that you have followed the
appropriate steps to tune your OS to suit Squid's particular needs, as
that is also required to prevent Squid from becoming bogged down in OS
limits.

If you want to prove it to yourself that many of these options are not
worth tweaking, Polygraph is pretty easy to use these days (though it
requires a couple of machines to set up the test environment). Let me
know if you find I'm wrong about any particular option.

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support