[Koha-bugs] [Bug 16088] Excessive CGI->new() calls hurting cache performace under plack

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon May 9 13:58:17 CEST 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16088

--- Comment #10 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
(In reply to Jonathan Druart from comment #3)
> For discussion
> With this patch, I get only 1 call to CGI->new (hard to do less:)) instead
> of 344 on a search with 20 results (default XSLT used).
> It's quite dirty but I have no idea how we could do another way (we could
> store it in the L1 cache instead?)

We certainly don't want language code to be propagated to shared persitent L2
cache ;). I think that some kind of extra simple L1 memory-only cache
implementation may come in handy anyway, for caching things that are specific
to the given script run. Something as simple as possible - eg.
Koha/Cache/Memory/Lite.pm, with get(), set() and clear() methods - no
expiration, deep copying etc. needed.

Having something like that, we can:

1) cache CGI object first (in plack startup CGI->new() override and eg. in
C4::Auth::get_template_and_user() as well)
2) use that cached CGI object in getlanguage() later - if it's a 1st call for a
given run
3) cache language code obtained in the 1st call for possible later uses so this
subroutine would not need to check CGI object again in subsequent calls
4) clear extra-simpe-L1-memory-only cache in the CGI override

By the look of it, language code returned by getlanguage() stays always the
same for a given script run, so it shouldn't introduce any regressions, at
least in theory.

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


More information about the Koha-bugs mailing list