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.
