Ускоряем 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-страниц.
Павел Гвоздь
14 июня 2019, 09:30
282
+10
Поблагодарить автора Отправить деньги

Комментарии: 3

Yar
Yar
14 июня 2019, 11:09
+1
С интересом прочитал о выполненных работах, хотя компонентом не пользуюсь…
Евгений Шеронов
14 июня 2019, 14:14
+2
Привет!

seofilter_crumbs_nested
— эта настройка для виртуального вкладывания хлебных крошек)
То есть не просто одну ссылку выведет — а все предыдущие к текущей вложенности.

То есть так: Телефоны -> Красные телефоны -> Красные iPhone -> Красные iPhone 64gb (где реальная категория только телефоны).

За исследование спасибо!
Давно хочу взяться за серьёзную переработку, версию 2.0 так сказать.
Возможно, эта статья поспособствует этому)

P.s. если можно, то глянул бы что происходит на том сайте.
Возможно, сразу выпущу обновление под такое количество.
    Павел Гвоздь
    15 июня 2019, 08:13
    0
    P.s. если можно, то глянул бы что происходит на том сайте.
    Сайт клиента, так что вряд ли.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.