On Fri, Jul 18, 2008 at 5:51 AM, Patrick May <[EMAIL PROTECTED]> wrote: > Tom, > >> First thoughts: why not Zend or Pear cache libraries? >> >> >> http://framework.zend.com/manual/en/zend.cache.theory.html#zend.cache.factory >> http://pear.php.net/package/Cache_Lite >> http://pear.php.net/package/Cache >> >> The pear packages are looking for maintainers - perhaps you could roll >> your work into that? > > Thanks, these were the sorts of libraries I wanted to check for reference. > >> >> So, what is your goal with this caching library? FE caching can be >> fixed with more boxes or a squid layer. Datasources can be harder to >> cache but will be much more valuable when you try to scale. > > My experience is that the broader the cache the less effective. Caches can > make sites appear un-responsive or oddly buggy to users. I've done reverse > proxy caching with Squid, but it's painting with an extremely large brush. > You can't target *part* of a response for caching. >
Agreed. Multiple layers of caching are also can be a pain to testing and debug. But even if I only I only served from that cache 10% of the time, I'd still want it there. > I also don't believe in "more boxes" all the time. While an important part > of scaling is adding more resources, it's also important not to waste the > resources you have. For example, you can cache the datasource.... or the > result set. If the two have the same effectiveness, then I'd rather cache > the result set because that extends the per-box capacity. > Yes, as long your data is tied to only one view. My experience has been that performance issues stem from the datasource rather than the FE rendering. Don't get me wrong, I used local, file based cache as well, but I cache the datasource separately. And for FE cache, you of course don't want to cache the view (or page module or widget or whatever) if your datasource fails. > If my application is failing to meet performance expectations, I like to > have on hand some caching tools to see if I can rescue it. And that would > be the purpose of this library. > Yes, this would be the quickest way to breath life into a fledgling or over-taxed application. Wouldn't require too much work and can handle user/session specific page modules. Tom http://www.liphp.org _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
