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

Regarding stability:
http://www.squid-cache.org/mail-archive/squid-users/201202/0356.html

Regarding writes in aufs: In the unmodified source code of 2.7, they are
sync.
Ref. to
/squid/squid-2.7.STABLE9-20110824/src/fs/aufs/store_asyncufs.h

/* Which operations to run async */
#define ASYNC_OPEN 1
#define ASYNC_CLOSE 0
#define ASYNC_CREATE 1
#define ASYNC_WRITE 0
#define ASYNC_READ 1

However, during real execution, the behaviour of LINUX disk subsystem will
come into effect: The deferred writes.
Actually, this is a grey area to me. Because so many parameters, also
depending upon kernel version
.
Looking into this in more detail, I must clarify my statement, that "writes
using aufs are sync":
"In the unmodified source code of squid 2.7 aufs performes only async reads,
file opens and file creates. However, because of the underlying disk
subsystem used in LINUX, writes will in essence be executed async as well."
(Which might also explain the #define ASYNC_WRITE 0 ??)
After rethinking my previous post then, this leads me to the consequence, to
agree, that probably aufs will in fact is the faster solution in LINUX in
all scenarious, because also the async (coded) writes of diskd finally will
depend executionwise upon the same underlying disk subsystem used.
Sorry for the confusion.

I have no benchmarks; because of my saturated disks, I simply looked into
ways to tune squid a bit.

--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Metrics-to-calculate-best-values-for-cache-mem-and-cache-dir-tp4508859p4511569.html
Sent from the Squid - Users mailing list archive at Nabble.com.