Re: Re: Would like to take over Cache Lite

I took a few minutes to evaluate the impact of memory based caching, using sysvmem. I was concerned that since the real value in the use case I mentioned in my last email was cutting out as much of the processing as possible, and essentially trying to make the request look more like a static html page request than a PHP request, the extra complexity of ANY processing would make the benefit of memory versus a modern fast disk irrelevant. My results, which are obviously very machine dependent, are shown below. These are from a sample program fetching 256 rows of small data (using the DB API) and echoing it with a trivial amount of formatting. Heavier formatting or use of a template engine would probably make the cache hits look far better than they do in my test. This was run on Debian/Lenny, using an Acer laptop with enough memory that it's unlikely swapping was a factor. The times were measured with XDEBUG. With Cache Lite caching to a disk file: 153147 uncached / 7933 cached = 19 With sysvmem: 111971 uncached / 446 cached = 251 The deviation in the uncached run times is from my sysvmem 'caching' code, which is very trivial and lightweight. This is not realistic, since it's tailored to the sample, and not embedded within Cache Lite. A better test would be to modify Cache Lite to support sysvmem, and thereby measure only the difference between disk and memory caching, using more or less the same framework. However, the magnitude of the difference (essentially a single order of magnitude) is consistent with what I would expect comparing disk to memory performance, and I think it suggests that a more careful comparison (as I suggested above) would be worthwhile. I will do this test in the next couple of days, along with a memcached base test. I would love to find a way to get another order of magnitude out of Cache Lite as a "content wrapper", but I'll be the first to concede that the overhead of talking to the memcached server may negate the benefit. Also, I'm not sure how realistic sysvmem is -- in a heavily loaded environment, I would think this could lead to swapping, and in a lightly loaded environment, a properly tuned disk system will buffer reads, so is it just 6 of one and half dozen of the other? I'm really curious what you folks think of this test and it's potential flaws. If you have any suggestions, I'd be happy to incorporate them into my methodology. Thanks, Ed On Sat, Jan 24, 2009 at 2:25 PM, Ed Shirey <elswaretech@gmail.com> wrote: > 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 >> >