Re: Re: Would like to take over Cache Lite

Ok,... So, as the newest and most unproven member of this group, I think it would be wise to limit my comments so as not to embarrass myself, but...I've yet to master that kind of wisdom. I have two points to make: #1 - I believe integrating memcached into cache lite DOES NOT contradict it's design objectives, and provides a SIGNIFICANT performance improvement in what is likely the most common use case, and #2 - I don't disagree that a fresh look at a robust caching API is a good idea. I think these points are separate from each other. #1 - memcached can be easily integrated to provide a 1 or 2 order of magnitude transparent performance improvement. My original use of Cache Lite was based on a specific use case -- 'semi-static' pages in an application that is 'framework heavy'. The folks who wrote it have layers of layers, and even though the code itself is relatively optimal, they're only able to serve a dozen or so requests per second on their server, simply because of the initialization process they go through to setup their framework. The pages are mostly static though. About 1 out of a thousand requests change data, and the other 999 send the same exact HTML output to the browser. I certainly wouldn't dispute that they could eliminate some of their framework to get a better result, but this kind of application design and "abstraction" is not uncommon, and often has some merit. Cache Lite is a PERFECT low-hanging solution for this -- without mucking with their app at all, I can get about an order of magnitude improvement by wrapping their output in Cache Lite. I realize people may use caching functionality for more complex use cases, but I think this is really Cache Lite's sweet spot. It seems like the bigger sites with more sophisticated caching needs have adopted memcached directly. So, noticing that there's a configuration option for "memory caching", I tried it out. It provided no improvement. After reviewing the code, it was clear why: this option does not really use a shared memory or other pure memory buffering solution, it simply provides a way to aggregate more complex use of Cache Lite into a single read of a "memory cache" file, so that subsequent calls can decompose this cache from an array. This is a great solution when you're making a series of calls into cache lite, but when you're simply buffering the entire browser stream, it doesn't improve performance at all. That's not to say this isn't a great feature -- it just doesn't address this use case. Note, though, that it was deemed an appropriate feature to add at some point, and consists of perhaps 20 additional lines of code. Now, since memcached is a module, once added to the site's configuration, it involves no additional parsing overhead or complexity. It appears to me that the API is pretty mappable to the Cache Lite core API, so that the introduction of this mechanism could be accomplished in say, 20 lines of code or so. Once done, this *should* provide an ADDITIONAL one or possibly two orders of magnitude of performance improvement, in a very transparent way. (I haven't tested it yet, but it's a pretty trivial addition - I guess I should have tested it and provided some numbers, huh). I'm suggesting memcached because it seems to be pretty popular right now, and is scalable across servers. There may be better solutions that allow use of shared physical memory -- I've not looked into this idea yet. It's possible that the overhead of accessing a memcached server is comparable to a simple file access on a fast hard drive. If this is true, then my assertion above would be invalid (I guess I need to write the code and test it!). #2 - An updated PEAR caching API is a reasonable proposal. The use case I described above, although a common one I believe, is just one of many. More sophisticated caching needs could benefit from a friendly API that provides more control and perhaps more sophisticated flushing algorithms that are transparent to the application, yet configurable. This sounds like it would be fun to work on. I don't think this negates the value of Cache Lite, though. This is a different tool for a different level of sophistication. Perhaps one way to measure the value of such a project is to ask "how does this improve, add to, or simplify existing packages such as memcached?". So there, I've probably said too much and embarrassed myself. You can strike me from the list now. If you decide not to, though, I'd love to help in whatever way I can. Thanks, Ed On Sat, Jan 24, 2009 at 9:21 AM, Helgi Þormar Þorbjörnsson <helgith@gmail.com> wrote: > On Fri, Jan 23, 2009 at 6:03 PM, Joe Stump <joe@joestump.net> wrote: >> >> On Jan 23, 2009, at 5:26 AM, Igor Feghali wrote: >> >>>> Cache is kinda .. dead I think - And most people i know think it has a >>>> weird design :-) >>>> Perhaps a new package is in order, Cache_Lite_Memcache that is API >>>> compatible or even just a new package with completely new design and >>>> approach to things. >>>> >>>> Perhaps Cache2 can be started ? Just thinking out loud now. >>> >>> Strong +1 for a totally new package. >>> I would go with the name "Cache_Memcache", plus I would suggest to >>> deprecate Cache in favor of it. >> >> So, at Digg, we have a whole Cache framework that includes a standard >> interface for Memcached and APC. It's container-based, much like MDB2/DB >> drivers. It also includes a "Local" cache (just a global array, basically) >> so the same request doesn't fetch a cached object more than once in a >> request along with a "Chain" driver that uses the chain of responsibility >> pattern (e.g. Is it in Local? No? APC? No? Is it in Memcached? Yes? Go and >> set it in APC and Local and then return it). >> >> It also has faux multi-get for the containers that don't support it, etc.. >> It, roughly, follows the Memcache interface from PHP and has some other >> syntactical sugar (e.g. $cache->my_key_name to get()). >> >> It wouldn't be terribly difficult to decouple this from our internal code. >> Let me see if I can sucker a few of my Diggers into refactoring and >> releasing it. > > That sounds awesome ! Maybe Ed and Micheal can coordinate with you on > that somehow, be it with reviews or help testing or whatever is > needed, perhaps *gasp* even contribute code :-) > > Ed, what do you think about this progress ? It seems like you might > not have to write the Cache_memcached but as I said above, you might > want to be involved with what Digg is prepared to release :-) > > Great to see this development ! > > Regards > Helgi >