@DStrine Can we prioritise this - it's about 20 minutes work + being aware of it at the team level & having a plan to revert if anything weird happens. Would be nice to get it done now as it should help with performance at UI level & reduce deadlocks (or at least give us a way to reduce them in our own scripts)

I've made the following change on frpm - ready to deploy.....

+++ b/civicrm/sites/default/civicrm.settings.php
 
+// mysql support for 5.7 locks - this is not yet the default
+// but should become the default once we can support successful prod testing.
+// https://github.com/civicrm/civicrm-core/pull/13854
+// note to use this we need to make more use of Civi::lockManager()->acquire();
+// in our own queue consumers.
+define('CIVICRM_SUPPORT_MULTIPLE_LOCKS', TRUE);

@Ejegg wanna check the change on frpm before I deploy - am doing the locks only first - that seems very safe - we can talk about when to enable Redis in terms of timing

Just noting that before redis was enabled the highest peak processing in the last 90 days was 13 donations per second - with a few peak over 10 per second. If we see this falling below that we will need to investigate cache-misses. I see a few cases where we might be missing the cache in redis monitor. Reasons for this are generally

1. treating a cachehit that returns FALSE as a cache miss
2. going to Redis rather than using a php cache in the first instance

Some related upstream work taking place - https://github.com/civicrm/civicrm-core/pull/14675