https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #1 from Jacek Ablewicz <ablewicz@gmail.com> --- Created attachment 49184 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=49184&action=edit Bug 16079 - Retrieving system preferences from database via DBIx is not fast enough Bug 13967 introduced some perfomance issues (80+ miliseconds added to the run time of the average CGI script, on the fast server). After Bug 11998, this is now efectivelly resolved for Koha + memcache setups, but Koha + Cache::Memory (= default caching system) setups are still affected. To address that, this patch reverts a small (most speed-sensitive) part of Bug 11998. Hopefully, this solution is only temporary, to be reverted when (if) better one will become available. Test plan: 1) apply patch 2) run t/* tests 3) drop database contents to trigger an installer, ensure that you can advance at least to the step #2 without encountering any problems -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jacek Ablewicz <abl@biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=16076 Depends on| |16068 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16068 [Bug 16068] System preference override feature (OVERRIDE_SYSPREF_* = ) is not reliable for some cache systems -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jacek Ablewicz <abl@biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #49184|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #3 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I don't know how this is relevant. In a near future, you will need to setup memcache (or similar) and plack. Koha won't be usable without using both of them. If we accept this patch, we also could revert all patches moving DBI calls to Koha::Objects :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jacek Ablewicz <abl@biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion CC| |abl@biblos.pk.edu.pl -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz, | |katrin.fischer@bsz-bw.de, | |kyle@bywatersolutions.com, | |martin.renvoize@ptfs-europe | |.com, | |pianohacker@gmail.com, | |tomascohen@gmail.com --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I think we need to talk more about comment 3, CCing other fellows. I personally think that we cannot support all the configurations and that Koha will only be usable with Plack and a caching system enabled. If it's not what everybody has in mind, we should discuss all together about that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #6 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to Jonathan Druart from comment #5)

I personally think that we cannot support all the configurations and that Koha will only be usable with Plack and a caching system enabled.

Yep, and apart from DBIx class loading penalty under CGI, soon Koha will require Moose as well (and/or Moo or whatever) and so on. +1 for depreciating setups w/o memcached (or another persistent caching system) in (eg.) 1 release cycle and non-plack setups (in 1-2 release cycles ?). That doesn't necessarily mean Koha should / needs to completely cease to work without plack and memcache (not in the near future at least), more like: all performance-related complains for non-plack setups could be by default redirected to /dev/null after that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, we are still testing without Plack not seeing response times as long so far - is it special pages that are affected? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #9 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Katrin Fischer from comment #8)

Hm, we are still testing without Plack not seeing response times as long so far - is it special pages that are affected?

A catalogue search with opac images displayed should make you wait for ~30sec. The problem is the hit to opac-image.pl which will load the DBIX::Class schema. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #11 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to Jacek Ablewicz from comment #6)

soon Koha will require Moose as well (and/or Moo or whatever)

Heh, it already does (in Koha/SearchEngine/* modules). I'm wondering why we don't preload it in plack startup (and why we don't preload many more heavy-weighted Koha and CPAN modules as well). And for the things we do preload - is there any particular reason for preloading them from scratch again and again per each 20 requests? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #13 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to Tomás Cohen Arazi from comment #12)

...

...

soon Koha will require Moose as well (and/or Moo or whatever)

Heh, it already does (in Koha/SearchEngine/* modules).

It shouldn't, see bug 16489, I just filled it.

OTOH, it would be kinda helpfull to left it as is, if we are willing to peddle plack more aggressively (just kidding). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #15 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- Apparently there is a substantial performance difference in regards of DBIx search speed between DBIx versions 0.08196 (in wheezy) and 0.082810 (in jessie). Simple DBIx searches (if we only want array of hashes as a result), with some additional tweaking (using DBIx::Class::ResultClass::HashRefInflator), are almost as fast as plain DBI in DBIx::Class v0.082810 (?). I uploaded some quick & dirty benchmarking code in Bug 16076, there seems to be quite a huge difference: # current master (08/07/2016) on Wheezy # (DBIx::Class version 0.08196, i7-3770 CPU @ 3.40GHz) # # $results = sysprefs_from_mysql(); ## 1.82 msec # $results = sysprefs_dbix_hashref_inflator(); ## 12.5 msec # $results = sysprefs_dbix_unblessed(); ## 17.6 msec # 3.22.x on Jessie (DBIx 0.082810, i7-930 CPU @ 2.80GHz) # # $results = sysprefs_from_mysql(); ## 2.52 msec # $results = sysprefs_dbix_hashref_inflator(); ## 3.51 msec # $results = sysprefs_dbix_unblessed(); ## 7.9 msec Can someone please confirm those results? I tested it on two (not exactly directly comparable) hardware setups - IMO, DBIx version is likely the most important difference, but I can't exclude the possibility that there may be some other factors involved. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 --- Comment #17 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- (In reply to Marcel de Rooy from comment #16)

DBIx::Class 0.08196 vs 0.082810

WHEEZY WITHOUT 16079 Mysql real 0m1.966s

Hash ref inflator real 0m16.663s

Unblessed real 0m20.411s

=== JESSIE WITHOUT 16079 Mysql real 0m2.092s

Hashref inflator real 0m2.991s

Unblessed real 0m6.603s

Thanks Marcel, good to know that speed improvements (both DBIx::Class 0.08196 vs 0.082810, and unblessed vs hashref inflator) are real, not just some weird local artefacts. I see that wheezy support got just depreciated, as of 16.11, in the last IRC dev meeting (unanimously :), so the possibly insufficient performance of the older DBIx::Class is most likely not to be a problem in the long term. Hashref inflator seems to be a lot better then unblessed (over 2x faster, almost as fast as pure DBI) especially in jessie; using it instead of unblessed may be well worth it in speed-sensitive places. Any ideas how to implement hashref inflator method / variant inside Koha::Object[s] without violating (too much ;) the underlying principles of Koha::Objects? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=15341 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16079 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |RESOLVED Resolution|--- |WORKSFORME CC| |dcook@prosentient.com.au --- Comment #19 from David Cook <dcook@prosentient.com.au> --- I don't think this is relevant anymore at least not when using Plack with Memcached which is the norm. -- You are receiving this mail because: You are watching all bug changes.