[dev] [commits] Horde branch master updated. 72ea817571b7bb561686a8d7d6f6cf8e8e7c6e24

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> The branch "master" has been updated.
>> The following is a summary of the commits.
>>
>> from: ef6afb339341b56d1f7ae650d1cf5dd5a954aeb1
>>
>> 72ea817 [mms] Store registry cache on the local filesystem.
>>
>> Summary:  
>> http://github.com/horde/horde/compare/ef6afb339341b56d1f7ae650d1cf5dd5a954aeb1...72ea817571b7bb561686a8d7d6f6cf8e8e7c6e24
>>
>> -----------------------------------------------------------------------
>>
>> commit 72ea817571b7bb561686a8d7d6f6cf8e8e7c6e24
>> Author: Michael M Slusarz <slusarz at horde.org>
>> Date:   Wed Jan 22 21:13:22 2014 -0700
>>
>>    [mms] Store registry cache on the local filesystem.
>>
>>    Horde_Cache is designed for *user* data.  Registry caching is a
>>    system-level cache so it doesn't fit well there.
>
> Uh, why? There is absolutely no reason to consider Horde_Cache for  
> user data only. It's a general purpose caching library and can very  
> well be used for both system-wide and user-level data.
> If there is any other reason to implement a separate, less flexible  
> caching for registry data, please explain.

Horde_Cache is a "general-purpose" caching library.  It is *NOT* the  
best solution in every caching situation though.  That is a very  
short-sighted approach.

So just like everything else we do... the first implementation is with  
the basic building blocks.  Then, when analyzing for bottlenecks, you  
can implement custom solutions.  This just happened with  
Horde_Imap_Client caching code ... we've had a Horde_Cache driver for  
years.  But recent analysis indicated there is a substantial overhead  
in using this generalized code (10%+) vs. using a backend specifically  
tailored for the backend required.  (And see #2 below... this also  
gives the option of using a different caching backend then the general  
Horde version, which may be advantageous).

This is no different than rewriting portions of C programs in  
assembly.  Sure... these portions of code work when written in C.  But  
that doesn't mean they are the best performing solution.  Cost/benefit  
analysis.

I stand by my previous statement.  Horde_Cache is not meant for  
"system" level caching like this.  (Otherwise, I personally would have  
long ago figured out how to bootstrap Horde_Cache with  
Horde_Autoloader_Cache rather than writing an entirely different  
caching mechanism in that library that is partially redundant).

Some other issues:

1. Just because someone hasn't configured Horde_Cache at the Horde  
level does not mean they should not get the benefits of registry  
caching.
2. Unlike other cache items, this information is parsed on every  
server access.  Your caching strategy/backend decision will almost  
certainly be different when faced between a choice of 'fast' vs.  
'needs to hold large quantities of data'.  We don't currently have any  
way of specifying which cache backend should be used with which  
subsystem as I wrote on the dev@ list ... the paradigm that a single  
cache backend is the correct solution is outdated.
3. This should absolutely not be a user-configurable option.  This is  
something that needs to just work, and work with good performance in  
every situation.  This new code will do that.  The old code wouldn't.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]