Ускоряем SeoFilter или почему хлебные крошки такие дорогие

Последнее время почти на каждом магазине встречаю компонент SeoFilter. Полагаю, что компонент пользуется спросом, т.к. позволяет очень точечно оптимизировать динамические страницы фильтра mSearch2. Вот и в этот раз ко мне обратился человек с задачей оптимизации скорости ИМ, на котором был установлен данный компонент.
Я уже однажды писал статью про оптимизацию фильтра каталога, реализованного на mSearch2, однако в этот раз дело было совершенно в другом…

Начав изучать выдачу DebugParser, я погрузился в лёгкое недоумение от того, что 3-7 секунд (в зависимости от страницы), проходило мимо логов. Не стану вдаваться в подробности и детальное описание отладки кода, скажу лишь, что мои изыскания привели меня к методу SeoFilter::findSeoLink.

Таблица класса sfUrlWord, которая несколько раз джоинится в запрос в данном методе, содержит более 600k строк. Не сказать, что это много, учитывая, что компонент генерирует огромное кол-во объектов в базе и постоянно выполняет туда запросы. К слову, товаров на сайте чуть более 2k, а полей в фильтре 11 штук (это вместе с ценовым слайдером).

Насколько я понял, данный метод выполняет запрос к базе и возвращает массив с данными страницы для формирования хлебных крошек. Делает он это несколько раз, в зависимости от того, сколько страниц в цепочке крошек. При чём отрабатывает он только при включённой настройке seofilter_crumbs_nested. Ни в документации к компоненту, ни на просторах Интернета я не нашёл ничего про эту настройку, а из описания я нифига не понял, поэтому до сих пор полагаю, что она отвечает за динамический вывод хлебных крошек при фильтрации товаров. Но отключив её и протестировав, работают ли динамические крошки, оказалось, что они работают. Хм, значит она нужна для чего-то ещё…

Увы, запрос я не оптимизировал, т.к. отключение данной настройки ничего не ломает на данном сайте. Однако, если это поможет, то я заметил, что дольше всего отрабатывает запрос с HAVING levels = 1, а быстрее всего HAVING levels = 3.

Вообще, я полагаю, что узкое место в запросе выглядит как-то так:

SELECT ..., COUNT(sfUrlWord0.id) as levels FROM ... HAVING levels = 1

Другими словами, стоит обратить внимание именно на то, как заменить этот кусок. Велика вероятность, что разбив запрос на пару и перетащив часть логики на сторону PHP, можно существенно ускорить этот метод.

Предлагаю обсудить, за что отвечает эта настройка и как можно ускорить данный метод на большом количестве SEO-страниц.

seofilter_crumbs_nested