[Koha] Batch check outs timing out after upgrade and migration

[Matthew Lindfield Seager]

Hi All,

I'm a Koha newbie so I hope this is the appropriate forum for this
question, please let me know if not!

I'm the ICT Manager in a small school in Phnom Penh that had a working Koha
installation. One of our physical servers died and, rather than replace it
to get back up to full redundancy, we decided to move our on-prem servers
to an IaaS provider (Linode).

In the process of restoring Koha onto the new server I discovered we were
running Koha 20.05 on the old server and 21.05 on the new server. I then
made the fateful mistake of proceeding with both changes at once (despite
knowing better 😔). I upgraded the old server to 21.05 and then backed up
and restored onto the new server (both Ubuntu 20.04 LTS). I also added TLS
using Let's Encrypt at the same time.

It all seemed to go smoothly but we're now experiencing slow performance
when checking out and looking up patrons and we're getting gateway timeouts
when we try to use Batch Check Out.

Does anyone have any tips on how to troubleshoot this? So far I've:

   - checked specs (new server is a "dedicated" 4GB VM with specs
   equivalent to or better than the old server)
   - tried to find any configuration differences between the old server and
   the new server
   - looked through the wiki pages on performance
   <https://wiki.koha-community.org/wiki/Performance> and tuning
   <https://wiki.koha-community.org/wiki/Koha_Tuning_Guide> to see if
   there's anything we'd done on the old server but not on the new

In the process I discovered that the old server was running on
MariaDB 10.3.31 whereas I installed MySQL 8.0.26 on the new server. Could
that be the source of all our issues or is that a red herring?

To rule out MariaDB as the issue I've tried backing up the new server and
restoring it on to an even newer server with MariaDB installed but so far
I've not been successful in getting Koha running on MariaDB, despite
successfully running the restore (after adjusting the SQL dump to change
from MySQL's `utf8mb4_0900_ai_ci` collation to MariaDB's
`utf8mb4_general_ci `).

Has anyone got any nuggets of wisdom? I fear our next best option might be
to create a new (MariaDB) server from the original back ups and manually
re-enter the past 4 days worth of borrowing and returns 😔

Regards,
Matt