[Koha-bugs] [Bug 8089] Use Koha::Cache everywhere

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8089

--- Comment #35 from Jonathan Druart <jonathan.druart at biblibre.com> ---
(In reply to comment #34)
> > 1/ I don't understand your test (t/Cache.t):
> >     ok(exists $myhash->{'anotherkey'}, 'Cache reset properly');
> 
> This is to confirm that after clearing a hash cache-tied variable values can
> be retrieved again. The cache was reset, but even after getting reset, the
> 'anotherkey' value can be retrieved

So the following test is not more complete?
  ok($myhash->{'anotherkey'} eq "anothervalue", 'Cache reset properly');

> > I think we expect from this patch a gain of performance.
> 
> No, definitely not. I think I mentioned this in my commit message. On an
> low-load system, caching for something as simple as sysprefs will be slower
> than just retrieving the data from MySQL without any cache. We'll see a
> performance improvement with frameworks/languages, which are slow to load
> from the database, but with anything that can be loaded from the database,
> the cache is going to be slower than MySQL. There are two reasons why
> caching sysprefs is important:
> 1) scalability-we retrieve dozens of sysprefs on every single page load.
> Load ten pages simultaneously, and that's 200+ sysprefs requested. Load a
> hundred pages, and you have thousands of database requests simultaneously,
> just for system preferences.
> 2) right now the way we do caching is not thread-safe, and you get
> inconsistent results depending on what server thread you hit.
> 
> We could probably improve performance by changing the serialization method
> used for caching (JSON::XS is supposed to blow everything else out of the
> water, performance-wise), but for an initial patch, I figured something
> using the default Storable serialization would be best.

You mentioned in the commit message that the patch will not improve
performance, not that it will be degrade them :)
I thought a gain after a 2nd refresh of the page would have observed, but it
was not the case.
1 second is so long (regarding the original 1.5s), I am wondering how it is
possible to recover it.

> > It will be very difficult to gain 1 second by caching some others stuffs.
> 
> If people are not concerned about scalability, they can simply disable the
> cache. That is one of the other advantages of this implementation. If you
> don't want it, you can disable it with minimal impact on performance.

By disabling you mean remove or unset the CACHING_SYSTEM env variable?
I am not a supporter of sysprefs but is it not a good way to have a quick
switch?

Sorry for all my questions, I am not an expert of cache issues :)

-- 
You are receiving this mail because:
You are watching all bug changes.