[Koha] Slow Koha OPAC login process - a bug? Workaround exists

[Michael Kuhn]

Hi

We're running a new host with Debian GNU/Linux 8 and Koha 16.11.04.

On 13 April I first wrote that sometimea when trying to login into the 
Koha OPAC it takes more than 30 seconds until the login process finally 
comes to an end, while the process "opac-user.pl" was eating up 99% of 
the CPU.

Some of you have kindly given my some hints but everything I tried was 
of no avail: logging mySQL slow queries, iotop, strace -c -p PID, 
tcpdump, checking logs (plack-error.log, opac-error.log etc etc), 
executing various time measurements of the Perl scripts, deactivating 
other programs (like Plack, EZproxy etc), enabling debugging for Plack, 
etc etc

Eventually I executed "strace -t -s 1024 -p PID" and tried to understand 
the output. I doubt I did but some lines gave me the idea the problem 
was connected with the card expiry date. The user data were migrated 
from another ILS which contained a card expiry date of 9999-12-31 for 
every user - I manually changed this to 2030-12-31 via SQL and all of a 
sudden the login process was quick as experienced elsewhere. So the 
problem feels like SOLVED by a workaround, at least in our Koha instance!

But meanwhile we have found out the following:

1. 9999-12-31 is a valid date accepted by MySQL (see 
https://dev.mysql.com/doc/refman/5.5/en/datetime.html)

2. The newly configured patron categories in our Koha instance all have 
an enrollment period of 999 months (strangely it's not possible to 
choose a higher number).

3. The migrated user data was imported via Koha menu "Tools > Patrons 
and circulation > Import patrons". NO ERROR occurred and all the data 
(including the date 9999-12-31) was correctly written into table 
"borrowers".

4. In Koha menu "Patrons > New patron" when a new patron is added with 
expiry date "31.12.9999" this is accepted WITHOUT ERROR. (the local Koha 
system preference "datetime" is set to "dd.mm.yyyy")

5. Trying to login into the Koha OPAC will immediately lead to described 
problem with the delayed login.

6. I tried step 4 on my own demo installation of Koha 16.11.00 with 
expiry date "31/12/9999" - there a dialogue appears saying "Invalid year 
entered in field dateexpiry". There is only a button "OK" - I clicked 
that and then saved the user data. This worked without further errors 
and the date can be found in field "borrowers.dateexpiry" as 
"9999-12-31". It seems rather strange to me that Koha should warn about 
an "invalid year" (whatever that means) but accepting it nonetheless. 
Trying to login with this user in the OPAC of my demo installation works 
quick as expected.

To me the behavior (described in steps 1-5) feels like a bug because if 
date 9999-12-31 is accepted by the patron import tool and also by MySQL 
then it shouldn't be necessary to change that date. (But it seems this 
problem is only existing on our Koha instance)

Also the behavior (described in step 6) feels at least like a minor bug 
because if Koha warns of an "invalid year" it should 1) be more explicit 
(what exactly is invalid about the year?) and especially it shouldn't 
allow to save that "invalid" year.

What do you think of this?

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch