[horde] Cache slowly filling up with driver File

[Arjen de Korte]

Citeren Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>
>> I use the filebased cache, which stores data on a tmpfs. Works fine  
>> except for one slight problem, the number of files cached doesn't  
>> stabilize at all, it keeps growing.
>>
>> Right after cleaning the cache partition, almost all cached files  
>> are listed in the 'horde_cache_gc', so eventually these will be  
>> caught during garbage collection. But I also see the number of  
>> files that are *not* listed growing every day (which as far as I  
>> can see, means these will never be removed).
>>
>> I see that in many places, no explicit lifetime is set when storing  
>> an entry in the cache (for instance, the information retrieved by  
>> the weather info), so these will never be GC'd as only files with  
>> non-zero lifetime will make it into the 'horde_cache_gc'.
>
> This isn't 100% true. When a cache value is requested from the  
> cache, a $lifetime parameter can also be supplied. So, e.g., in the  
> case of Horde_Service_Weather, we specify the $lifetime when reading  
> the cache. If the $lifetime expired, then the cache library will (in  
> the case of a file based backend) unlink the cache file. Granted,  
> since this only happens when the specific cache key is requested, I  
> see how this could lead to certain cache files perhaps never being  
> GC'd if, again using Horde_Service_Weather as an example, weather  
> location was requested once, and never requested again.
>
>> Wouldn't it be a better idea to let *any* file stored in the  
>> filebased cache timeout to prevent them from piling up?
>
> For some data, sure, it might make sense to add a $lifetime  
> parameter to the set() method if it doesn't already exist, but not  
> all data necessarily should be automatically expired.

I put a Horde::debug statement in the File.php set() method that logs  
data with lifetime zero (ie, cache entries which will never be GC'd).  
The resulting log file worries me a little, since all entries seem to  
be Horde_History_Log ones. Since the data is also stored in the  
database, I think storing them in the cache permanently is not needed  
and instead the default cache lifetime would be appropriate for this  
data:

--- History.php.orig    2014-11-18 20:16:53.300494861 +0100
+++ History.php 2015-04-27 21:57:01.069877539 +0200
@@ -169,7 +169,7 @@ abstract class Horde_History

          $history = $this->_getHistory($guid);
          if ($this->_cache) {
-            $this->_cache->set('horde:history:' . $guid,  
serialize($history), 0);
+            $this->_cache->set('horde:history:' . $guid,  
serialize($history));
          }

          return $history;

--- History/Composite.php.orig  2014-11-18 20:16:53.300494861 +0100
+++ History/Composite.php       2015-04-27 22:01:07.033756773 +0200
@@ -115,7 +115,7 @@ class Horde_History_Composite extends Ho
              $history = new Horde_History_Log($guid, $data);

              if ($this->_cache) {
-                $this->_cache->set($cid, serialize($history), 0);
+                $this->_cache->set($cid, serialize($history));
              }
          }

For many cache backends this is probably not an issue (since they will  
automatically evict old cache entries), but the filesystem cache  
relies solely on the GC to do this.

-- 
This message was sent from a mailinglist subscription address.
For off-list replies, you must remove the address extension.