[nycphp-talk] Cache package suggestions

Rob Marscher rmarscher at
Fri Aug 17 12:57:23 EDT 2007

> I’m reviewing caching packages and am looking for suggestions.
> Smarty cache — since I use Smarty anyway. I’ll probably use Smarty  
> cache for general page result caching, but perhaps not for lower  
> layer objects?
> PEAR cachelite — looks simple and efficient. Could be good for  
> caching small “widgets”, misc paramters, etc.
Both of these are file based, so you have some disk i/o overhead.   
I've used both.  Smarty is oriented a bit more towards page output  
caching, but I don't see why it wouldn't be possible to store  
anything else... you just need to appropriately serialize the data to  
a string.  Cache_Lite has more methods for dealing with other types  
of data.

> ZendFramework Zend_Cache — multiple backend storage options is  
> nice, but may be overkill for my needs — until I realize I need  
> memcached of course.
This one gets my vote because of the multiple backend options - APC,  
Memcache, ZendPlatform, SQLite, and file based.  Only SQLite and file- 
based backends support the "tag" grouping - but it's not that  
important a feature. I would say don't use tagging so you can easily  
switch the backends.  Also, I don't really see how it's anymore  
overkill than PEAR.  You don't need to include the whole framework as  
demonstrated in this article.

> Also... All packages generally store cache results based on a  
> lifetime. But what if I want to store results using a date, not a  
> lifetime. An example would be something that changes once per day.  
> Ideally, I’d like this updated for the first hit after midnight  
> each day. Suggestions?
Use a lifetime of 86400 and manually invalidate it sometime after  
midnight.  It's not reliable that it would stay always at the same  
time.  You could set no expire time for the cache (or a really huge  
expire time if your cache system requires an expiration) and then  
have a cron process that runs after midnight and updates the cache  
programmatically.  That's probably better.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the talk mailing list