Проблема возникла на одной из последних версий (19 или 20) при использовании в качестве сервера баз данных MySQL 5.7 (это важно).
Визуально это выражалось в очень долгом массовом добавлении товаров в корзину и при создании новых страниц. Из лога меделнных запросов выяснилось, что торможение возникает в /classes/system/subsystems/models/data/umiObjectsCollection.php в запросе:
SELECT `ord` FROM `cms3_objects` WHERE $typeCondition ORDER BY `ord` DESC LIMIT 0,1Итоговоый запрос выглядит:
SELECT `ord` FROM `cms3_objects` WHERE `type_id` IN (список) ORDER BY `ord` DESC LIMIT 0,1;Смотрим EXPLAIN и видим, что MySQL пытается сперва отсортировать таблицу (а ней больше 12 млн записей) по полю ord, и только потом сделать выборку по type_id.
Это как-то выглядит не очень хорошо... Первое, что пришло в голову - создать дополнительный индекс:
ALTER TABLE `cms3_objects` ADD INDEX `search_max_ord` (`type_id`, `ord`);В клиентской части стало заметно лучше! Но с добавлением страниц осталась проблема: ЮМИ собирает в IN множество типов страниц и в все очень тормозит. Пришлось лезть в ядро и заменять указанный запрос на
SELECT MAX(`ord`) FROM `cms3_objects` WHERE $typeCondition Страницы стали добавляться очень быстро.
Но зато теперь у менеджеров по 40 секунд стал открываться список заказов. К сожалению, победить эту проблему не удалось. Оружием последнего резерва стала замена MySQL на MariaDB. У нее оптимизатор работает более удачно и даже без правки ядра сайт ожил.
Вывод, ради которых я это писал.
Если ЮМИ медленно работает - проверьте версию ПО. Возможно, простая замена сервера баз данных решит вашу проблему.