Some aspects:
- You are only using aufs. I consider it good for larger objects, but
regarding small ones (<=32kb), rock should be faster. So I suggest some
splitting of cache_dirs based on obj size.
- Be careful when setting up the filesystem for your cache_dirs on disk. I
made the experience, that this will have a huge impact on performance. I
consider HDDs reliable, so I take the risk of losing some cache content in
case of diskfailure (which happend very seldom to me) and use an ext4-fs,
stripped down to the very basics (no journal, timestamps etc.).
-AFAIK, SMP does not do shared aufs. That means, in your config you take the
risk of having the same file cached multiple times, in different cache_dirs.
So you might consider having multiple workers for rock-dir, but only one for
the larger stuff, stored using one single HUGE aufs. However, will need
configure opt
'--enable-async-io=128'
- To smooth the access from clients, you might consider using delay-pools,
to limit the risk of some bad guys sucking your bandwidth by having an upper
limit on download spead.
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SMP-vs-Single-Process-Performance-tp4659034p4659035.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Mon Mar 18 2013 - 10:07:16 MDT
This archive was generated by hypermail 2.2.0 : Tue Mar 19 2013 - 12:00:06 MDT