using CHI directly to use all of it's advantages
As some of you allready know, Jonathan Swartz had presentation about CHI: Universal caching for Perl at YAPC::NA. Video recording is available at: http://ics.webcast.uwex.edu/mediasite/Viewer/?peid=b503ecb42c18452a9f4a95b73... It got me thinking about our new Koha::Cache layer. For a start, I would love to use CHI directly and make it required depenency for Koha since it has following features which we already use: - memcached back-end - making our own memcache implementation obsolete - fastmmap back-end - ditto - DBI cache - making mysql query cache problem solvable way than DBD::Goper suggestion from http://wiki.koha-community.org/wiki/Performance#MySQL_tuning - memoize - very nice syntax: my $customer2 = $cache->compute($name2, "10 minutes", sub { get_customer_from_db($name2) }); Which I would prefer to our existing Koha::Cache API. It would also save us quite a bit of code. CHI has powerfull statistics which basically obsolete my idea of writing statistics gathering code through Koha. I would love to have this in next release, since this is more-or-less my last major gripe with current Koha code (short-term goal[1]), so if I would love to hear feedback. 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177 My more long-term goal is to know more about Koha's data-access patterns (you are again advised to examine performance wiki page if you haven't up to this point). In most simple sense, only think which is big unknown is wheater we can find sane key namespace schema which will allow us to good-enough cache invalidation scheme. I strongly think that time-outs are useful just for OPAC, not for intranet use! It seems to me that CHI redis back-end (which can introspect keyspace with keys *) and my "weekly push master in production because of plack" approach might bring us to better understanding how our Model layer might look like, allmost like reverse engeeniring existing code access patterns which has proven to bring a lot of low-hanging fruits so far. Only disadvantage I can think of is that CHI isn't packaged in stable Debian but it is in wheezy so Robin would not need to package it forever, just for little while :-) -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
Dobrica,
As some of you allready know, Jonathan Swartz had presentation about CHI: Universal caching for Perl at YAPC::NA. Video recording is available at:
http://ics.webcast.uwex.edu/mediasite/Viewer/?peid=b503ecb42c18452a9f4a95b73...
It got me thinking about our new Koha::Cache layer. For a start, I would love to use CHI directly and make it required depenency for Koha since it has following features which we already use: - memcached back-end - making our own memcache implementation obsolete - fastmmap back-end - ditto
We don't actually have a fastmmap implementation yet. That is on my to-do list, though not very high.
- DBI cache - making mysql query cache problem solvable way than DBD::Goper suggestion from http://wiki.koha-community.org/wiki/Performance#MySQL_tuning - memoize - very nice syntax:
my $customer2 = $cache->compute($name2, "10 minutes", sub { get_customer_from_db($name2) });
Which I would prefer to our existing Koha::Cache API. It would also save us quite a bit of code.
If we were to make CHI a core dependency, I see no reason not to have a Koha::Cache wrapper subclassing CHI so that if we had to globally adjust cache settings we could do so. We would use the exact same interface as that exposed by CHI but would be able to transparently handle Koha-specific creation options (e.g. any sysprefs for turning the caching on or off, or selecting a non-default backend).
CHI has powerfull statistics which basically obsolete my idea of writing statistics gathering code through Koha.
I would love to have this in next release, since this is more-or-less my last major gripe with current Koha code (short-term goal[1]), so if I would love to hear feedback.
1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
My more long-term goal is to know more about Koha's data-access patterns (you are again advised to examine performance wiki page if you haven't up to this point).
In most simple sense, only think which is big unknown is wheater we can find sane key namespace schema which will allow us to good-enough cache invalidation scheme. I strongly think that time-outs are useful just for OPAC, not for intranet use!
This is why I do not think memoize is a good idea. Useful cache invalidation with memoize -- at least as I read the code implementing the memoize function -- is impossible. Using compute around a method call would be a much better option. If you want to make it appear seamless without modifying the underlying function, do the computation in a private method and surround a call to that with commute in a routine that does nothing other than run the compute (or invalidate the cache if that is what is desired).
It seems to me that CHI redis back-end (which can introspect keyspace with keys *) and my "weekly push master in production because of plack" approach might bring us to better understanding how our Model layer might look like, allmost like reverse engeeniring existing code access patterns which has proven to bring a lot of low-hanging fruits so far.
Only disadvantage I can think of is that CHI isn't packaged in stable Debian but it is in wheezy so Robin would not need to package it forever, just for little while :-)
CHI is very easy to package. I already created packages for myself. +1 from me on making CHI a core dependency. -1 on decentralizing cache access with memoize and direct 'use CHI' throughout the Koha/C4 namespace +1 on making Koha::Cache a transparent wrapper around CHI and using compute instead of the existing get/set whenever possible In summary, I almost entirely agree with you, and would sign off on a patch changing our caching to CHI only provided it kept the code that interfaces directly with CHI neatly cordoned off from the rest of the system. Regards, Jared P.S. If we need to replace the SQL query cache with a local cache, doesn't this mean we're doing it wrong?
On Thu, Jun 14, 2012 at 03:23:59PM -0400, Jared Camins-Esakov wrote:
- very nice syntax:
my $customer2 = $cache->compute($name2, "10 minutes", sub { get_customer_from_db($name2) });
Which I would prefer to our existing Koha::Cache API. It would also save us quite a bit of code.
If we were to make CHI a core dependency, I see no reason not to have a Koha::Cache wrapper subclassing CHI so that if we had to globally adjust cache settings we could do so. We would use the exact same interface as that exposed by CHI but would be able to transparently handle Koha-specific creation options (e.g. any sysprefs for turning the caching on or off, or selecting a non-default backend).
This makes total sense. So, I can expose CHI's ->compute method through Koha::Cache wrapper and use it that way. This might even bring us additional benefit of caching for OPAC and not caching for Intranet for example :-)
CHI has powerfull statistics which basically obsolete my idea of writing statistics gathering code through Koha.
I would love to have this in next release, since this is more-or-less my last major gripe with current Koha code (short-term goal[1]), so if I would love to hear feedback.
1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
My more long-term goal is to know more about Koha's data-access patterns (you are again advised to examine performance wiki page if you haven't up to this point).
In most simple sense, only think which is big unknown is wheater we can find sane key namespace schema which will allow us to good-enough cache invalidation scheme. I strongly think that time-outs are useful just for OPAC, not for intranet use!
This is why I do not think memoize is a good idea. Useful cache invalidation with memoize -- at least as I read the code implementing the memoize function -- is impossible. Using compute around a method call would be a much better option. If you want to make it appear seamless without modifying the underlying function, do the computation in a private method and surround a call to that with commute in a routine that does nothing other than run the compute (or invalidate the cache if that is what is desired).
I look at memoize as a easy way to find our which parts of our data model should be cached. Once we find contended places, we can remove memoize and implement proper compute for that part of code. It's more development help than long-term solution.
+1 from me on making CHI a core dependency. -1 on decentralizing cache access with memoize and direct 'use CHI' throughout the Koha/C4 namespace +1 on making Koha::Cache a transparent wrapper around CHI and using compute instead of the existing get/set whenever possible
In summary, I almost entirely agree with you, and would sign off on a patch changing our caching to CHI only provided it kept the code that interfaces directly with CHI neatly cordoned off from the rest of the system.
+1 from me about this one.
P.S. If we need to replace the SQL query cache with a local cache, doesn't this mean we're doing it wrong?
Sure, but it's low-hanging fruit, and this is currently a huge show-stopper if you want to have MySQL on another machine since network latency is killing our performance. -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
Le 15/06/2012 11:32, Dobrica Pavlinusic a écrit :
I look at memoize as a easy way to find our which parts of our data model should be cached. Once we find contended places, we can remove memoize and implement proper compute for that part of code.
quick answer (I'll answer more completely later) About contended places, I see 3: * systempreferences that call each syspref one by one. Result in 60 SQL for each page. It would be better to load all sysprefs in one SQL. The patch should be easy to write (we had it at BibLibre, it has been lost in limbo between 3.2 and 3.4 iirc) * languages_* stuff. I spoke of this with chris_c during the KohaCon12 hackfest, to know if he understand how this code works. He don't. I don't. If anyone understand, he is welcomed, but I think (and chris agrees) that the best option should be to drop all this code and re-write it from scratch. An acceptable circumvent could be to put in a hash those tables that never changes (and user can't change through Koha interface anyway). If a new language arise, just fix the hash ! * XSLT parsing. That's quite consuming (and first for XSLT result list !), caching them will have the greatest effect ! So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, On Fri, Jun 15, 2012 at 5:42 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 15/06/2012 11:32, Dobrica Pavlinusic a écrit :
I look at memoize as a easy way to find our which parts of our data model should be cached. Once we find contended places, we can remove memoize and implement proper compute for that part of code.
quick answer (I'll answer more completely later)
About contended places, I see 3: * systempreferences that call each syspref one by one. Result in 60 SQL for each page. It would be better to load all sysprefs in one SQL. The patch should be easy to write (we had it at BibLibre, it has been lost in limbo between 3.2 and 3.4 iirc)
Dobrica said he plans on reimplementing this. It's a showstopper for Plack. (side note: the Plack-unfriendly hash could easily be replaced by a Plack-friendly in-process CHI cache, if the consensus were that fastmmap was a bad idea)
* languages_* stuff. I spoke of this with chris_c during the KohaCon12 hackfest, to know if he understand how this code works. He don't. I don't. If anyone understand, he is welcomed, but I think (and chris agrees) that the best option should be to drop all this code and re-write it from scratch. An acceptable circumvent could be to put in a hash those tables that never changes (and user can't change through Koha interface anyway). If a new language arise, just fix the hash !
This should never have been in the database. Also, there is a 1-1 relationship between almost all the language tables. We should just have sort of configuration file with that information (maybe in YAML?). Also, using just one type of language code might be nice. * XSLT parsing. That's quite consuming (and first for XSLT result list
!), caching them will have the greatest effect !
It is inefficient, but I have a very surprising performance statistic. Processing the XSLT for the result list is *not* the most inefficient part of the results page rendering! Getting authorised value images is the most inefficient! (I was shocked when I discovered that, too... it makes no sense at all, but that's what it is) So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-) 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/
This should never have been in the database. Also, there is a 1-1 relationship between almost all the language tables. We should just have sort of configuration file with that information (maybe in YAML?). Also, using just one type of language code might be nice.
* XSLT parsing. That's quite consuming (and first for XSLT result list
!), caching them will have the greatest effect !
I'd love to see if using Turbomarc would give us a visible XSLT processing boost. Index data reports 2x speed increases.
It is inefficient, but I have a very surprising performance statistic. Processing the XSLT for the result list is *not* the most inefficient part of the results page rendering! Getting authorised value images is the most inefficient! (I was shocked when I discovered that, too... it makes no sense at all, but that's what it is)
I recall this from a while ago... basically every time you get the authorised value images, you have to parse out the MARC framework, or some massively overwrought mechanism. Before, though, this was done whether or not you even USED the images, but that's since been patched. A more thorough implementation of the auth value images would go a long way here. -Ian
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Am 15.06.12 11:32, schrieb Dobrica Pavlinusic: [...]
P.S. If we need to replace the SQL query cache with a local cache, doesn't this mean we're doing it wrong?
Sure, but it's low-hanging fruit, and this is currently a huge show-stopper if you want to have MySQL on another machine since network latency is killing our performance.
Actually, when putting the database on a separate machine, the performance should increase, not decrease, because the load is distributed. As is, Koha does not scale, since it only runs performant when everything is one the same machine. I think an analysis of which SQL statements are executed in which order, and which are called repeatedly, could be the basis of work to make Koha talk more efficiently to the database. To those interested in this, I can higly recommend "Refactoring SQL Applications" by Stéphane Faroult. Available from O'Reilly in print and as e-book. - Marc
participants (5)
-
Dobrica Pavlinusic -
Ian Walls -
Jared Camins-Esakov -
Marc Balmer -
Paul Poulain