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. > - 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. >> - **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. > -> 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. 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. 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
