Cache::Memory must be removed (21955)
Hi devs, I am still recovering from my holidays and I think I caught a quite big fish. After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache. What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance. Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!) To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request) Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly! Cheers, Jonathan
+1 ________________________________ Van: koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> namens Jonathan Druart <jonathan.druart@bugs.koha-community.org> Verzonden: woensdag 5 december 2018 20:20:35 Aan: koha-devel Onderwerp: [Koha-devel] Cache::Memory must be removed (21955) Hi devs, I am still recovering from my holidays and I think I caught a quite big fish. After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache. What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance. Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!) To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request) Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly! Cheers, Jonathan _______________________________________________ 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/
Indeed, this is a big behavior error we found a few month ago. I think we shared it in mailing but I can find how. This is a big issue when you change an HTML systempreference like "opacnav", you see the change and when refresh its gone (you see the other plack worker). We solved by installing memached everywhere. Maybe we can just disable Cache::Memory when Plack mode is used. Then I say we need a C4::Context->is_psgi() method : https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76477 Programing is sometimes so wierd ;) Regards, Le 05/12/2018 à 20:20, Jonathan Druart a écrit :
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ 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/
-- Fridolin SOMERS <fridolin.somers@biblibre.com> BibLibre, France - software and system maintainer
I agree on its removal too. On Thu, 6 Dec 2018, 8:26 am Fridolin SOMERS <fridolin.somers@biblibre.com wrote:
Indeed, this is a big behavior error we found a few month ago. I think we shared it in mailing but I can find how. This is a big issue when you change an HTML systempreference like "opacnav", you see the change and when refresh its gone (you see the other plack worker). We solved by installing memached everywhere.
Maybe we can just disable Cache::Memory when Plack mode is used. Then I say we need a C4::Context->is_psgi() method : https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76477
Programing is sometimes so wierd ;)
Regards,
Le 05/12/2018 à 20:20, Jonathan Druart a écrit :
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ 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/
-- Fridolin SOMERS <fridolin.somers@biblibre.com> BibLibre, France - software and system maintainer _______________________________________________ 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/
Get rid of it! +1 El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (< jonathan.druart@bugs.koha-community.org>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ 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/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered. In any case, +1! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Tomas Cohen Arazi Sent: Friday, 7 December 2018 2:44 AM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Cache::Memory must be removed (21955) Get rid of it! +1 El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org> >) escribió: Hi devs, I am still recovering from my holidays and I think I caught a quite big fish. After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache. What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance. Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!) To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request) Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly! Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached. I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack. --Ere David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
I talked with Ere on IRC, but prefer to let a note here as well. Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made). I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :) Cheers, Jonathan Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
Hi Jonathan, I'd be very happy if you could wrote something on the wiki, I'm a little bit confused by all those cache... Le 07/12/2018 à 16:36, Jonathan Druart a écrit :
I talked with Ere on IRC, but prefer to let a note here as well.
Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made).
I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :)
Cheers, Jonathan
Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
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/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
I have stolen this existing page and wrote some info about our cache mechanism: https://wiki.koha-community.org/wiki/Cache_handling_in_Koha Feel free to ask if you need more info or if something is still not clear enough. Cheers, Jonathan Le mer. 19 déc. 2018 à 05:33, Paul Poulain <paul.poulain@biblibre.com> a écrit :
Hi Jonathan,
I'd be very happy if you could wrote something on the wiki, I'm a little bit confused by all those cache...
Le 07/12/2018 à 16:36, Jonathan Druart a écrit :
I talked with Ere on IRC, but prefer to let a note here as well.
Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made).
I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :)
Cheers, Jonathan
Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
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/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ 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/
Great, thanks ! An idea: couldn't we also cache the xslt display of biblios, as it requires quite a long time to be done, and it's a data that change rarely ? Le 21/12/2018 à 16:51, Jonathan Druart a écrit :
I have stolen this existing page and wrote some info about our cache mechanism: https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
Feel free to ask if you need more info or if something is still not clear enough.
Cheers, Jonathan
Le mer. 19 déc. 2018 à 05:33, Paul Poulain <paul.poulain@biblibre.com> a écrit :
Hi Jonathan,
I'd be very happy if you could wrote something on the wiki, I'm a little bit confused by all those cache...
Le 07/12/2018 à 16:36, Jonathan Druart a écrit :
I talked with Ere on IRC, but prefer to let a note here as well.
Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made).
I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :)
Cheers, Jonathan
Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
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/ -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ 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/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
"There is a patch for that" :) See bug 14476 Le ven. 21 déc. 2018 à 13:01, Paul Poulain <paul.poulain@biblibre.com> a écrit :
Great, thanks !
An idea: couldn't we also cache the xslt display of biblios, as it requires quite a long time to be done, and it's a data that change rarely ?
Le 21/12/2018 à 16:51, Jonathan Druart a écrit :
I have stolen this existing page and wrote some info about our cache mechanism: https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
Feel free to ask if you need more info or if something is still not clear enough.
Cheers, Jonathan
Le mer. 19 déc. 2018 à 05:33, Paul Poulain <paul.poulain@biblibre.com> a écrit :
Hi Jonathan,
I'd be very happy if you could wrote something on the wiki, I'm a little bit confused by all those cache...
Le 07/12/2018 à 16:36, Jonathan Druart a écrit :
I talked with Ere on IRC, but prefer to let a note here as well.
Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made).
I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :)
Cheers, Jonathan
Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
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/ -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ 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/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ 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/
Look at XSLT_Handler ? ________________________________ Van: koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> namens Paul Poulain <paul.poulain@biblibre.com> Verzonden: vrijdag 21 december 2018 17:01 CC: koha-devel Onderwerp: Re: [Koha-devel] Cache::Memory must be removed (21955) Great, thanks ! An idea: couldn't we also cache the xslt display of biblios, as it requires quite a long time to be done, and it's a data that change rarely ? Le 21/12/2018 à 16:51, Jonathan Druart a écrit :
I have stolen this existing page and wrote some info about our cache mechanism: https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
Feel free to ask if you need more info or if something is still not clear enough.
Cheers, Jonathan
Le mer. 19 déc. 2018 à 05:33, Paul Poulain <paul.poulain@biblibre.com> a écrit :
Hi Jonathan,
I'd be very happy if you could wrote something on the wiki, I'm a little bit confused by all those cache...
Le 07/12/2018 à 16:36, Jonathan Druart a écrit :
I talked with Ere on IRC, but prefer to let a note here as well.
Enabling Cache::Memory if Plack is not running will not help as we have the L1 (in memory) cache, which is used in any cases (and flushed under Plack before a request is made).
I do not know how is our caching system understood by the team. I can try and write something on the wiki if it can help. Hint: there is no black magic :)
Cheers, Jonathan
Le ven. 7 déc. 2018 à 04:55, Ere Maijala <ere.maijala@helsinki.fi> a écrit :
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
_______________________________________________ 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/
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/ -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ 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/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries _______________________________________________ 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/
For the record, I mixed the internal memory cache with Cache::Memory, so... +1 for removal of Cache::Memory. --Ere Ere Maijala kirjoitti 7.12.2018 klo 9.55:
I'm a bit hesitant on this. I understand running without a cache makes things like tests easier, but Cache::Memory is actually a pretty useful fallback. There's a lot of code in Koha that does redundant fetches of e.g. framework data, and without caching I'm afraid it will slow down significantly. Cache::Memory is very handy when developing stuff to speed up execution of e.g. batch utilities when you don't want to mess with constantly flushing Memcached.
I would like to propose another approach for considerarion: disable Cache::Memory only if running under Plack.
--Ere
David Cook kirjoitti 7.12.2018 klo 1.52:
I’ve noticed some caching issues but haven’t had time to investigate too deeply. I wonder if this relates to what I’ve encountered.
In any case, +1!
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
*From:*koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Friday, 7 December 2018 2:44 AM *To:* Jonathan Druart <jonathan.druart@bugs.koha-community.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
Get rid of it!
+1
El mié., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>>) escribió:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F
_______________________________________________ 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/
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
+1 --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Wed, Dec 5, 2018 at 2:20 PM Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ 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/
As the plack is recomended way of running Koha, I am for removing Cache::Memory too Josef On Fri, Dec 7, 2018 at 2:24 PM Kyle Hall <kyle.m.hall@gmail.com> wrote:
+1 --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Wed, Dec 5, 2018 at 2:20 PM Jonathan Druart < jonathan.druart@bugs.koha-community.org> wrote:
Hi devs,
I am still recovering from my holidays and I think I caught a quite big fish.
After an interesting track game I will explain why I am suggesting to remove Cache::Memory that is currently used as fallback for the L2 cache.
What I tried to fix: Jenkins is complaining about selenium tests (regressions.t) failing on 18.05, it is a succession of events and bugs that were not linked at first glance.
Here are the different steps I went though: - On bug 21426 we noticed that USE_MEMCACHED was not taken into account. If set to "no" the default memcached config was defined in the koha-config.xml file anyway - A new regression selenium test was added on bug 21777 to catch the presence of an audio alert on the circulation page - Investigating the failing tests I noticed that koha-testing-docker was not setting the memcached config on the 18.05 branches (I guess the image has not been rebuilt yet) search_utf8.t output "Warning: script running in daemon mode, without recommended caching system (memcached)." - I also find that [% Koha.Preference('AudioAlerts') %] did not return the value set by the tests, but the value that the DB has before the tests were launched => It is a cache issue! - ...but only when memcached is not set... - Reading Koha::Cache->new we can notice that Cache::Memory is used for the L2 cache when memcached is not defined in the config
And so we have the problem: If a value is set in the cache by a Plack worker, it will not be available from another one, as the L2 cache is not shared (!)
To recreate easily the problem you can: - remove the memcached config - edit intranet-bottom.inc and add ===[% Koha.Preference('AudioAlerts') %]=== - restart plack - Modify the value of AudioAlerts (using the UI) - Reload the page (reload several times if the value is still correct, it will depend on which worker will serve the request)
Solution: I am considering removing Cache::Memory unless somebody else has a better idea Bug 21955 - Cache::Memory should not be used as L2 cache
Note that it should not affect a lot of people as everybody is supposed to have memcached configured and working correctly!
Cheers, Jonathan _______________________________________________ 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/
_______________________________________________ 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/
-- Josef Moravec josef.moravec@gmail.com
participants (10)
-
David Cook -
Ere Maijala -
Fridolin SOMERS -
Jonathan Druart -
Josef Moravec -
Kyle Hall -
Marcel de Rooy -
Paul Poulain -
Renvoize, Martin -
Tomas Cohen Arazi