[nycphp-talk] Cache package suggestions
Rob Marscher
rmarscher at beaffinitive.com
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.
http://devzone.zend.com/node/view/id/1221
> 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.
-Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070817/90e0d5bc/attachment.html>
More information about the talk
mailing list