[Discussion Tech] Cache handling in koha
Hi, I'm just starting a thread to discuss this topic so we make some decisions and we can continue improving Koha in this aspect. As far as I can remember there are a few issues with this: 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration. I introduced the use of ENV (from Apache vhost definition) for storing memcached servers configuration data on Bug 6193. This was done for being able to cache the koha-conf.xml configuration variables (prior to that, memcached info was saved in koha-conf.xml itself and thus not-cacheable). When coding that I realized that memcached was being initialized everywhere we needed it. And namespaces where not always consistent (KOHA and koha alternatively, this might not be a problem if this happens to be case insensitive, anyway, it looked bad to me). I then exported the object memcached and the ismemcached variable in C4::Context. This first patch (koha-conf.xml in memcache, and memcached object available for every other lib that includes C4::Context) has been pushed. Then there's a second patch, that removes several memcached configuration validation and initialization code from the rest of the libs, and reuses that variables from C4::Context. I tested it to work flawlessly, but things around it halted when other proposals raised. I like mi approach. I like how the resulting code looked, I wont hide it. But I don't need it to be accepted at all, maybe the other proposals are far better. The only thing I missed on this cache thing was more feedback. Back to the ENV use I think we must make a desicion: - Do we want to cache koha-conf.xml ? If the answer is no, then we can revert that patch. And we are done. If the answer is yes, we can deal with it is storing the settings in the database, but this will make it difficult to memoize the function reading. Or leave it as it is now. I don't agree it is a problem to move those settings to the vhost definition, it could be even moved into a separate file with an include sentence in the vhost definition for convenience (/etc/koha/memcached.conf and Include in vhost definition...) 2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached? Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example, someone writes a method, other memoizes it, but doesn't know that a third method relies on data returned by the first mehotd being 'online'. As-is, memoize_memcached doesn't provide a proper way of invalidating data automatically. As said in a previous email: we will end up hooking all the data writing methods so they invalidate all the memcached store, or those methods the writer knows have to do with the current. Almost like making it explicit, but just for writers. In which case it is better to implement the second option, making everything explicit: The second approach means we have to hook every function to handle its caching, and cache invalidation. Its advantage is that being explicit, but requieres a lot of work and we will end up having business logic mixed with cache handling code, which is not a problem per-se. Just thinking. If we are planning to go on with memoization, I made a proposal on IRC (which had zero responses) to add memoize_memcached an array of references to data invalidation methods, so we don't have to hook every method. The Memoize::Memcached dev told me to take over the lib as he isn't maintaining it nor working on perl anymore. I'd like to do that, but I halted my work on that until it is more clear that it is not a waste of time. Ok. I'd like to re-read this words I wrote, but I'm just back from holidays and my bosses need a lot of answers for a lot of stuff I didn't finish last year, right now, so... Regards To+
Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]:
1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration.
My 2¢ here is that we should use ENV. The main logic behind this is that it means the only thing you can't cache is the ENV vars, which no one does anyway. As for cache invalidation and memoisation, it's something best approached very slowly and carefully as it's a Hard Problem. I don't really have any concrete suggestions on that front though. “There are only two hard things in Computer Science: cache invalidation and naming things”. — Tim Bray quoting Phil Karlton -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
2012/2/8 Robin Sheat <robin@catalyst.net.nz>
Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]:
1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration.
My 2¢ here is that we should use ENV. The main logic behind this is that it means the only thing you can't cache is the ENV vars, which no one does anyway.
Personally, I feel that everything that is configurable should be configurable from the interface (i.e. sysprefs), but that seems like a valid reason to use ENV, so I withdraw my objections. Let's get Koha caching! Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08/02/2012 22:59, Robin Sheat a écrit :
Tomas Cohen Arazi schreef op wo 08-02-2012 om 12:42 [-0300]: I've started the wiki page for this discussion http://wiki.koha-community.org/wiki/Cache_handling_in_Koha
1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration.
My 2¢ here is that we should use ENV. The main logic behind this is that it means the only thing you can't cache is the ENV vars, which no one does anyway. I fully agree, and vote ENV as well !
As for cache invalidation and memoisation, it's something best approached very slowly and carefully as it's a Hard Problem. I don't really have any concrete suggestions on that front though.
I've discarded the 2nd part of this mail about the memoization on the wiki page, I think it's another topic (that I agree must be investigated) - -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPNPKQAAoJEK81SonuhyGosTMH/16+eq4TuSgJ54bzZnrE9hqg HFcHjCEDQ+oGNMgU+9DiIgZZ5JLwaqZEqBxX4wBzQrJjUkqKgkT2i/f4pBau8yX4 GiKcdDfg8+4cfUEsrLr8ySWaaca2TciVQI32zsPG/3KBfByuDOB+kJmB2Lpzbdrg dKzOE7ZxXJUqcm+x0wzIPXN3zym0SDOHRaMRPRcQZ6Qb0lzmaS1OyRBXGtYXJGfc 6RCaxL54uDC98XrmxRy8bTI1G8G5cV79pEgt649CFZeFey/bkzL9bjMcpCSaL9UV t99fE90GK4mmZRHDjQDyn1t9Und/reu93z8CnFRCgs+pVUzuI1JY8RWDkY4riZw= =4m/z -----END PGP SIGNATURE-----
Tomas Cohen Arazi <tomascohen@gmail.com>
Back to the ENV use I think we must make a desicion: - Do we want to cache koha-conf.xml ?
Yes, I think so. We were burning time on every request reloading it, weren't we? [...]
2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached?
Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example,
Is there a good list of the example disadvantages somewhere? Have other projects made this decision faced with similar circumstances, and can we see their reasoning? Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
At 10:18 AM 2/9/2012 +0000, MJ Ray wrote:
Tomas Cohen Arazi <tomascohen@gmail.com> [snip]
2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached?
Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example,
Is there a good list of the example disadvantages somewhere?
Have other projects made this decision faced with similar circumstances, and can we see their reasoning?
Disclaimer: my knowledge of memoization dates back to FORTRAN (fluid dynamics, harmonics and orbital calcs and was mostly used in conjunction with polynomial functions.) Is there enough repetitive math in Koha to justify memoization? I've been looking at caching (specifically memcached 1.4.13) for faster access to "text" (as opposed to calculated numeric values) in the general sense of page rendering and search results which I see as the bulk of what is returned (and therefore time cost) by a client request. The biggest problem that I appear to be facing at this point is coordinating the zebra cronjob with a discreet cache. The more static Koha files (pl, tt, inc) have not [yet] posed difficulties. I retained caching for the sql content again based on "text" versus "math results", as most examples of memoization appear to be primarily used for math functions (see for example <http://brooke.blogs.sqlsentry.net/2010/02/caching-and-memoization.html>) If I'm way off-track from what you folks have been working on, please point me in the right direction. I'd be more than happy to look into an example of a specific case where you have felt that memoization might be advantageous. Best regards - Paul
On Thu, Feb 9, 2012 at 11:35 AM, Paul <paul.a@aandc.org> wrote:
At 10:18 AM 2/9/2012 +0000, MJ Ray wrote:
Tomas Cohen Arazi <tomascohen@gmail.com>
[snip]
2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached?
Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example,
Is there a good list of the example disadvantages somewhere?
Have other projects made this decision faced with similar circumstances, and can we see their reasoning?
Disclaimer: my knowledge of memoization dates back to FORTRAN (fluid dynamics, harmonics and orbital calcs and was mostly used in conjunction with polynomial functions.)
Is there enough repetitive math in Koha to justify memoization? I've been looking at caching (specifically memcached 1.4.13) for faster access to "text" (as opposed to calculated numeric values) in the general sense of page rendering and search results which I see as the bulk of what is returned (and therefore time cost) by a client request. The biggest problem that I appear to be facing at this point is coordinating the zebra cronjob with a discreet cache. The more static Koha files (pl, tt, inc) have not [yet] posed difficulties.
I retained caching for the sql content again based on "text" versus "math results", as most examples of memoization appear to be primarily used for math functions (see for example <http://brooke.blogs.sqlsentry.net/2010/02/caching-and-memoization.html>)
If I'm way off-track from what you folks have been working on, please point me in the right direction. I'd be more than happy to look into an example of a specific case where you have felt that memoization might be advantageous.
You are right on asking for clarification as Koha is using Memoization in a different way as usual. Memoization is normally used to trade space (in the stack) for computing time (doing the math). This ussually happens trough the life of the main loop of the app. In this case, Koha has been using memoization libs that have a persistent storage (memcached) that lives until they reach their TTL that caches the results of function calls as a way to avoid coding the cache stuff: the Memoize lib does a trick that creates a wrapper around your functions so you don't need to worry about that stuff. Hence, we are using memoization libs, to make the implementation of caching easier. Regards To+
Op 10-02-12 03:35, Paul schreef:
Is there enough repetitive math in Koha to justify memoization? I've been looking at caching (specifically memcached 1.4.13) for faster access to "text" (as opposed to calculated numeric values)
Generalise "math" to "functions that take input and produce output based just on that", and that's a large amount of most programs. In the case of Koha, a lot of them are relatively slow operations: talking to zebra, talking to a database, and so on. Robin.
At 08:43 AM 2/10/2012 +1300, Robin Sheat wrote:
Op 10-02-12 03:35, Paul schreef:
Is there enough repetitive math in Koha to justify memoization? I've been looking at caching (specifically memcached 1.4.13) for faster access to "text" (as opposed to calculated numeric values)
Generalise "math" to "functions that take input and produce output based just on that", and that's a large amount of most programs. In the case of Koha, a lot of them are relatively slow operations: talking to zebra, talking to a database, and so on.
Thanks Robin. But I'm afraid you've lost me to a great extent. Queries to a database (be it zebra or mysql) are "one-offs" dependant on client input; and yes they are the slow point (high server time cost) and need to operate from memory rather than a HD read, hence "caching" in some form or another. But how does memoization improve on the concept that all functions are|can be cached in a more "classic" manner (as can be mysql and possibly zebra.) The concept of memoization is to eliminate *repetitivity* (classic case; memoize 17! and calculating either 15! or 19! reduces to 2 operations.) Could you give a specific Koha scenario where you feel memoization could be advantageous? I'm not trying to be "contrary" -- quite the opposite, I've been spending some effort on improving server response time and would be more than happy to go the extra mile to improve matters (and happy to spend some time in the sandbox.) Best regards - Paul
Paul schreef op do 09-02-2012 om 19:21 [-0500]:
But how does memoization improve on the concept that all functions are|can be cached in a more "classic" manner (as can be mysql and possibly zebra.) The concept of memoization is to eliminate *repetitivity* (classic case; memoize 17! and calculating either 15! or 19! reduces to 2 operations.)
Well, the definition is slightly different but closely related. More or less, it can be used as a fancy way of saying "caching function results." Assume that every request for a syspref goes to the database, if we replace that with something that does it once and caches it, then that's giving us something that will speed up every operation requiring that syspref (and while composing many pages, I expect that the same syspref is hit a good number of times.) However, in the Perl world anyway, it's made quite invisible. This is a Perl module commonly used for this: http://perldoc.perl.org/Memoize.html and it actually uses recursive maths functions as examples, but the approach can generalise to other things. Mostly to speed up slow, repetitive data accesses. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Hi, I'm just starting a thread to discuss this topic so we make some decisions and we can continue improving Koha in this aspect. As far as I can remember there are a few issues with this:
1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration. Unless i've missed something or someone opinion, everybody agrees that
Le 08/02/2012 16:42, Tomas Cohen Arazi a écrit : the use of ENV is better, because it will result in caching koha-conf.xml itself. (I add my vote to this option) Unless someone object in the next 3 days, i'll consider the decision is taken, and will push bug 6193 patch, and subsequent patches will have to consider caching is retrieved from here. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 15/02/2012 18:16, Paul Poulain a écrit :
I will push bug 6193 patch, and subsequent patches will have to consider caching is retrieved from here.
I just pushed bug 6193, and have updated status of caching related bugs: * bug 6019 has been marked RESO-INVALID * bug 7248 and 7249 have been marked "Patch Doesn't apply". However, some ideas behing 7248 are good and it should be rewritten I've added to my pre 3.8 release notes something about this change : existing install will have to update their memcache server configuration, to switch from koha-conf.xml to koha-httpd.conf -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (6)
-
Jared Camins-Esakov -
MJ Ray -
Paul -
Paul Poulain -
Robin Sheat -
Tomas Cohen Arazi