Re: [squid-users] Re: Metrics to calculate 'best' values for cache_mem and cache_dir?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 28 Mar 2012 10:36:44 +1300

On 28.03.2012 08:37, babajaga wrote:
>>I've read (for Linux at least) aufs is superior to diskd,<
>
> I have my doubts. First of all, it might depend upon the version of
> Squid
> you want to use.
> I use 2.7, and, looking at the source code for aufs, ony reads are
> async.
> Having some discussion with Amos already regarding this issue, he
> stated,
> that async writes were not enabled because being "unstable".
> Might be different in other versions, though, but, to be shure, it
> needs
> checking the source code, because it is a conditional compile (ref.:
> store_asyncufs.h).
>
> And, in case only reads are async, then it needs further
> verification,
> whether diskd or aufs should be faster.
> Because according to my first glance at the code for diskd, diskd
> does async
> writes by default.
> Most likely, diskd has more overhead. But, in case of low hit rate
> for the
> cache, I suspects, the performance gains because of async writes
> might put
> diskd into favour.
>

diskd/ufs/aufs have roughly the same code from squid-2.6 to current
stables. Based on Adrians research in 2.7 we _think_ the AUFS problem on
BSD is that AUFS write operations involve blocking operations, which
Linux kernel implementation evade in the background but BSD hits head
on. There are architectural differences in squid-3.x which may come into
play but are not expected to unless the bug info is wrong.

> Actually, I am checking this issue myself for my own stressed squid,
> running
> already in production (LINUX, too).
>
> In case, the "writing" considers aufs to be generally faster than
> diskd, it
> looks like, it is ignoring the risk of "unstable" write ops.

Thank you. Are you able to post the particulars of this research how it
was measured, with what versions and what outcome please? this info
could be of help to a lot of people.

Amos
Received on Tue Mar 27 2012 - 21:36:47 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 28 2012 - 12:00:04 MDT