On 02/01/2013 09:42 AM, Luciano Ruete wrote:
> I've tested with
>
> maximum_object_size_in_memory 64 KB
>
> And now I have both cache_dir AUFS and rock caching objects and growing
> at the same time, so thanks for that.
>
> But I don't understand the logic behind this, because from the docs
> about maximum_object_size_in_memory
> you read:
>
> "This should be set high enough to keep objects
> accessed frequently in memory to improve performance whilst low
> enough to keep larger objects from hoarding cache_mem."
>
> So, i don't see how this can interfere with saving large cache objects
> into a cache_dir, when the idea of this directive is just preventing
> larger object to hoarding cache_mem... can you elavorate on this?
Do HTTP responses that you want to cache have a Content-Length header?
If there is no Content-Length header, then, AFAIK, Squid will only cache
them to disk if Squid can cache them in memory (or if the whole response
has been received when the decision to cache on disk has to be made).
[ Why? I have not researched the motivation behind this, but it is how
caching code have been written long time ago. It is possible to relax
this restriction by rewriting the relevant code and possibly adding more
configuration options to control this behavior. ]
If there is a Content-Length header, then there is probably some other
bug or dependency. Tracking it down would require studying detailed
debugging logs -- not something you can easily do on your own,
unfortunately. Consider filing a bug report.
> Another thing that happens is that rock cache_dir always start from 0
> every time squid is restarted, is that the expected behavior?
No, it is not. Rock, just like ufs, should preserve cached content
across restarts (and does in my tests). How do you know that "cache_dir
always start from 0"? Please make sure you do not look at cache
statistics that is printed by Squid workers. Look at mgr:storedir stats
returned by diskers. Workers do not load rock store indexes, diskers do.
Someday, we will find a way to render these stats in a less misleading way.
HTH,
Alex.
Received on Fri Feb 01 2013 - 19:04:57 MST
This archive was generated by hypermail 2.2.0 : Sat Feb 02 2013 - 12:00:06 MST