Как я оптимизировал xenforo

Значимый прорыв формирует отрасль ИИ: guru_89 16 минут назад Как я оптимизировал xenforo Средний 23 мин 898 Серверное администрирование * PHP * Качество кода * Серверная оптимизация * Кейс Из песочницы История о том, как я загнал главную страницу форума с 88 запросов до 15, выяснил, что половину работы делал впустую один невинный аддон, и в конце снял ещё четверть серверного времени строчкой в конфиге — не сломав при этом ничего из того, что работало. А заодно — полная документация на стек из четырёх своих расширений и preload, на которых форум сейчас и держится. СодержаниеПовод заглянуть под капотЧто показал debug: главная под пользователемДымящийся пистолет: водяной знак и N+1Почему я правлю не аддон, а расширениеГостевой page cache: он уже работаетРеклама оказалась не врагом, а союзникомЕщё две N+1: Featured и обложки трендингаЭффект identity map, который удваивал запросыСчётчики гостей и роботов, которых нетOPcache preload: минус четверть времениМиниатюры, которые зря переспрашивали серверВесь стек разом: что в итоге работаетSG Boost: из чего собрался аддонSG SQLite Cache: кэш в оперативной памятиSG Sphinx Search: поиск мимо MySQLSG Root URLs: адреса от корня сайтаСкрипт sg-preload.

php: разборИнструменты, которыми я мерилКак правильно замерять (и как я трижды ошибся)Чему меня научили ложные цифрыИтогиПовод заглянуть под капотФорум у меня работает быстро, и поводов лезть внутрь вроде бы не было. Но «быстро» — это ощущение, а я хотел цифру. У XenForo есть встроенная debug-панель: добавляешь в config.

Технические детали

php флаг — и внизу каждой страницы появляется сводка по времени, памяти и, главное, полный список SQL-запросов с таймингами и EXPLAIN. Включил, привязав к своему IP, открыл несколько типовых страниц и стал смотреть. Debug, привязанный к IP, кажется безобидным — но если у вас работает гостевой page cache (а к концу этой статьи он будет работать), есть тонкий момент.

Ядро сохраняет в кэш то, что отрендерило. Если страницу для кэша сгенерирует ваш заход с debug — панель со всеми SQL-запросами и путями сервера ляжет в кэш и будет отдаваться всем подряд несколько минут. Поэтому правило железное: померили — выключили $config, и только потом тестируем кэш.

Тайминги по страницам оказались разные. Статьи и темы — отличные, 9–19 запросов, трогать нечего. А вот главная под залогиненным пользователем выбивалась из ряда: 88–90 запросов.

Отраслевые последствия

Гостевая главная при этом показывала 49 — тоже подозрительно много для страницы, которая по идее должна отдаваться из кэша почти целиком. Стало понятно, куда копать. Что показал debug: главная под пользователемЯ выгрузил полный список всех 88 запросов и стал читать его глазами.

И почти сразу в нём проступил паттерн — один и тот же запрос, повторяющийся снова и снова:SELECT * FROM xf_sp_watermark_permanent WHERE attachment_id = ? Он шёл по три раза на каждое вложение, да ещё и повторно для тех же вложений в разных местах страницы. Я насчитал около сорока таких запросов из восьмидесяти восьми — почти половину.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.