Hi Toby, sorry that I wasn't able to answer earlier...
Am Donnerstag, 27. März 2008 schrieb Tobias Schlitt: > Hi Thomas! > > On 03/27/2008 10:03 PM Thomas Nunninger wrote: > >> I started desigining the new features for Cache 1.4, which should > >> realize hierarchical caching. Since this topic is not trivial, I > >> started with a short summary of requirements and problems to be > >> solved. > >> > >> Please review this and state your comments. > > > > I think, the idea is quite nice. But I guess, implementing this in > > a good and fast way, isn't that easy... Here are some > > comments/questions: > > > > - Do you want to provide a possibility to choose between the use > > cache storage depending on the cache item type? E.g.: never store > > the user object on file system because it may be faster to reload > > from database; never store images in local RAM because there is not > > enough place for that. (Maybe this could be solved using several > > caching stacks for different ojects.) > > I would suggest your latter idea. Adding additional meta information > about the content of an item is not a good idea. We already need to > add some of this meta information, but adding semantics sounds > generally like a bad idea to me. I agree. > > - For me, it's not really clear, when you want to replace from top > > to bottom and vice versa. (Maybe the following covers a little bit > > too much replacement strategies in detail that could be application > > specific - but I want to point to the fact that there are perhaps > > some implications in the design document that are contrary.) > > The idea is the following: > > 1. Level: Local memory. Very fast cache, but very limited. > 2. Level: APC on another server. Quite fast, but still limited. > 3. Level: HD on and NFS share. Not that fust, but huge. > > The idea is to store most frequently used data on level 1, still > frequently used data on level 2 and not very often used data on level > 3. Yes, I got that. Perhaps I was not clear enough with my questions. > >> - **Bubbling restored data up through the cache stack** > >> According to the replacement strategy, cache items need to be > >> placed into higher levels of the hierarchy, as soon as they get > >> restored from a deeper level, to make them available faster on > >> subsequent restore requests. For more information see the > >> `Replacement strategies`_ section. > > > > -> Does this imply that new items are always stored in the slowest > > cache storage in the beginning? > > In the fastes, since they were most recently used. Ok, I think, I got it now. First I thought, _new_ items need to bubble up in the stack. I guess, you talked about "old" items which are no longer in the fastest cache. If they are requested again, then you bubble them up. But still one question: I thought, it is up to the developer to choose the replacement strategy. So if you have a LFU strategy, a new item perhaps does not go into the local RAM but some level down. (Perhaps that's why I thought about putting new items in the slowest cache from the beginning (see next paragraph). A cache item that is used many times will prove this soon and bubble up. But - while thinking about it some more - I don't know if it is possible to implement this easily.) > > -> Is it really true, that a cached item needs to go to a higher > > level if it is requested? Or should there be some strategy, like > > Most Frequently Used: if a cache item from file system is requested > > more than X times in the last Y seconds, put it in memcached. This > > may be a little bit slower for frequently used items in the > > beginning (till they reached the RAM). But it should reduce the > > replacements to a minimum. > > This strategy is not really possible, since the utilization is > primary driven by the number of possibly stored items. In addition, > always the Least Frequently Used (LFU) items are replaced (the Most > frequently Used ones are automatically preferred this way). Just to > give an example for a strategy. There might be multiple strategies > available, later. > > >> Propagate in store > >> ^^^^^^^^^^^^^^^^^^ > > > > and > > > >> Propagate on replacement > >> ^^^^^^^^^^^^^^^^^^^^^^^^ > > > > -> Does this imply that new items are always stored in the fastes > > cache storage in the beginning? If yes, there is another big con: > > on applications that permanently produce many new cache items, even > > items that are only used a few times are allowed to replace > > frequently used items from the fastes storage. > > If you have more writes that reads, this kind of storage is generally > not a good idea. It is optimized for reading. Of course, caching is always for reading :-) > However, if this is > necesaary, we might abstract the mechanisms that far, that users can > decide on this storage strategy, too. On cost of performance (as > usual) of course. Like written above: perhaps in that case it's easier to implement different caching strategies in the application for different cache item types. Thanks and have a nice weekend Thomas > > Thanks for your input! > Regards, > Toby > -- > Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards > > Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer > > [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
