My total hit ratio decreased in ~2 times from 40% to 20% (it could be cold cache but it lasted at this level for a day without sign of improvement).
I'll retry tests with making sure there're no Vary header and will also try 1 worker with shared cache tomorrow. But even if it is this bug looks like caching works as expected in squid 4 so it'll be better solution than messing up with headers probably.
On Mon, Jan 15, 2018 at 10:26 AM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 01/14/2018 10:53 PM, Ivan Larionov wrote:
> After migrating squid from non-SMP/aufs to SMP/rock memory cache hit
> ratio dropped significantly. Like from 50-100% to 1-5%.
This could be a side effect of not supporting Vary caching in shared
memory: https://bugs.squid-cache.org/show_bug.cgi?id=3806#c9
> And disk cache hit ratio went up from 15-50% to stable 60-65%.
I hope your total/combined hit ratio improved overall.
> it looks like in SMP/rock mode squid avoids using memory for small
> files like 1-3KB but uses it for 10KB+ files.
No, there is no such size-discrimination code in Squid.
> I started tracking down the issue with disabling disk cache completely
> and it didn't change anything, I just started to get MISS every time for
> the URL which was getting MEM_HIT with an old configuration. Then I
> changed "workers 2" to "workers 1" and started getting memory hits as
> before.
For a clean apples-to-apples test, make sure you use
"memory_cache_shared on" when using a single worker without rock cache_dirs.
> Am I doing anything wrong? Which debug options should I enable to
> provide more information if it seems like a bug?
Vary caching should be fixed as well, of course, but perhaps there is
another problem we do not know about. I would start by eliminating Vary
as the known problem. When using a test transaction, make sure the
response does not have a Vary header. Or configure Squid to log the Vary
header and remove the corresponding transactions when computing
adjusted-for-Vary memory cache hit ratio.
HTH,
Alex.
With best regards, Ivan Larionov.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
