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.
