Re: [SQU] current CVS ... diskd config args changed ...

As Adrian explained a few days ago in response to a similar question, it
is probable that if CPU and memory are not constraining factors, then
yes, it will increase performance by a small margin.

Since you're using Linux, why not go with async i/o? It is proven to be
faster than diskd by about 10% (probably as much or more than you could
expect for multiple diskd directories). 2.4 has a solid async
implementation now (much improved over 2.3 by some good work done by
Henrik on the aufs code). I haven't done a lot of testing of the most
recent aufs, but I'm confident enough in it that we'll be moving our
systems over to it in the next month or so, if not sooner.

DiskD is primarily a means of working around the (at the time, I do not
know the current status) lack of kernel level threads in FreeBSD. It is
not as fast as aufs, in any version of Squid that I've tested, though it
is quite stable and certainly faster than a standard Squid compile.

Phil Pierotti wrote:

> So then I'm going to have to ask the obvious question.
>
> I have a Dual PIII/500 with 1GB of RAM and 4 x 18G drives (7200rpm).
>
> Running RH7/2.4.2 , ReiserFS (notail,noatime) and Squid 2.4 with DiskD.
>
> Given that for me adding RAM is entirely doable, but faster CPUs or
> Faster/More drives is not, would I gain anything by seperating each drive
> into 2 or maybe 3 seperate cache_dir statements, rather than just one per
> drive?
>
> ie on the theory that multiple diskd per drive would mean that IO requests
> could possibly queue up per disk at the OS/Filesystem level and any OS level
> elevator sorting (or something) might maybe optimize disk IO performance
> some.
>
> Thanks,
> Phil P

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

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html