Производительность 1С-Битрикс - обзор раздела
Раздел о том, почему сайт на 1С-Битрикс тормозит и что с этим делать по шагам, а не хаотично. Сначала измерить, потом убрать запросы в цикле, потом закешировать и только потом масштабировать железо. Здесь разобраны все виды кеша платформы и то, чем они отличаются друг от друга. Рядом - композитный сайт, веб-кластер и альтернативные бэкенды хранения: PostgreSQL, Redis, memcached. Разработчику это даёт не список технологий, а порядок: дорогая инфраструктура почти никогда не первый шаг.
Как устроено
Раздел организован по тем же пяти уровням, о которых говорит первая статья. Уровни такие: код и запросы, автокеширование компонентов, управляемый и тегированный кеш, композитный сайт, инфраструктура. Это буквальная карта статей раздела, а не просто план чтения. У каждого уровня, кроме самого первого, есть отдельная статья. Подниматься по ним имеет смысл строго по порядку. Пропуск уровня почти всегда кончается дорогим решением - кластером или сменой СУБД. Оно лечит то, что решалось бы бесплатно правкой одного запроса.
Монитор производительности - не шестой уровень, а инструмент. Он решает, на какой из пяти уровней вы сейчас смотрите. Его отчёт «Разработка» показывает разбор по компонентам: сколько запросов делает каждый и кешируется ли он. В большинстве проектов узкое место именно там, на первом-втором уровне, а не в инфраструктуре. Статья про монитор - это способ не гадать, а измерить. Её читают прежде, чем переходить к композиту, кластеру или новой СУБД.
У четвёртого и пятого уровня по паре статей, и они отвечают на разные вопросы. Их легко перепутать местами. Композитный сайт разделён на две статьи: устройство в разделе «Компоненты и шаблоны», эксплуатация здесь. Эксплуатация - это настройка, сброс кеша и диагностика. Механизм при этом один, а не два разных. А вот «Веб-кластер» и «База данных» - не части одного целого, а две независимые оси. Кластер отвечает на вопрос «как распределить нагрузку между серверами». Это репликация, распределённый memcached с согласованным хешированием, централизованные сессии. «База данных» отвечает на другой вопрос: «каким бэкендом хранить данные». Это PostgreSQL вместо MySQL, Redis для кеша и сессий на одном сервере, HandlerSocket, вертикальный шардинг. Решения ортогональны: можно взять PostgreSQL без единого дополнительного сервера, а можно собрать кластер на обычном MySQL.
Один и тот же memcached в двух статьях раздела означает разные вещи. В «Базе данных» он снимает кеш и сессии с диска одного сервера. В «Веб-кластере» - распределённый кеш на нескольких нодах. Без согласованного хеширования отказ одного сервера кеша обрушивает на базу лавину промахов. Смысл технологии зависит от масштаба, на котором её разворачивают. Статья, в которой она упомянута, - подсказка, о каком масштабе речь.
Что нужно сделать
| Нужно | Смотрите |
|---|---|
| Найти, что именно тормозит на странице | Обзор и оптимизация запросов |
| Перестать ходить в базу за одним и тем же | Кеширование |
| Замерить время генерации и число запросов штатно | Монитор производительности |
| Отдавать первый экран из статики и не ломать личные блоки | Композит: эксплуатация |
| Развести нагрузку на несколько серверов | Веб-кластер |
| Настроить базу, вынести кеш в Redis или memcached | База данных |
С чего начать
Новичок или первая оптимизация тормозящего проекта. Не начинайте с кеша или кластера. Сначала «Обзор и оптимизация запросов» - там сквозные правила и ссылка на монитор для измерения. Дальше «Кеширование», и только после этого статьи про инфраструктуру.
Оптимизация существующего проекта под нагрузкой. Включите «Монитор производительности» и найдите отчётом «Разработка» конкретные некешированные компоненты. Это почти всегда быстрее и дешевле, чем следующий шаг. Дальше по уровням: «Кеширование», затем «Композитный сайт» (эксплуатационная часть - устройство разобрано в разделе «Компоненты»).
Рост за пределы одного сервера. Когда код, кеш и композит уже настроены и упираются в железо, остаются два пути. «Веб-кластер» распределяет нагрузку между серверами, «База данных» меняет бэкенд хранения. Это разные решения одной проблемы. Выбор зависит от того, что именно упирается: процессор веб-нод или сама база.
Темы раздела
- Обзор и оптимизация запросов: сквозные правила уровня кода - с них начинается любая оптимизация, до кеша и инфраструктуры.
- Кеширование: все виды кеша платформы и то, чем управляемый и тегированный отличаются от обычного.
- Монитор производительности: не отдельный уровень, а инструмент измерения - что выяснить, прежде чем чинить.
- Композит: эксплуатация: настройка, сброс кеша и диагностика - устройство технологии разобрано в разделе «Компоненты».
- Веб-кластер: распределение нагрузки между серверами - репликация, сессии, распределённый memcached.
- База данных: смена бэкенда хранения - PostgreSQL, Redis, HandlerSocket, вертикальный шардинг.
Практика раздела
- Композит на практике - статика, динамические области, сброс - статика, динамические области, сбои.
- Запросы к базе - поиск медленных и работа с планом - медленные запросы и индексы.
- Медленный сайт на практике - где искать и что чинить - где искать причину и что чинить.
Частые вопросы
Чем статьи «Веб-кластер» и «База данных» отличаются, если в обеих есть memcached?
Масштабом развёртывания одной и той же технологии. В «Базе данных» memcached или Redis снимают кеш и сессии с диска одного сервера - это вопрос выбора бэкенда хранения. В «Веб-кластере» memcached распределён по нескольким нодам, и там на первый план выходит согласованное хеширование: без него отказ одного сервера кеша перетасовывает все ключи и лавиной нагружает базу. Статьи не конкурируют - это независимые оси: локальный бэкенд и распределение по серверам можно комбинировать или применять по отдельности.
Композитный сайт - это одна технология или две разные статьи о разном?
Одна технология, две статьи по разным вопросам. «Композитный сайт» в разделе «Компоненты и шаблоны» - про устройство и адаптацию шаблонов компонентов: динамические зоны, голосование, классы Frame. Статья «Композит: эксплуатация» здесь, в «Производительности», - про то, что происходит после включения: режимы хранения, сброс кеша по коду и по расписанию, диагностика и поведение JavaScript. Читать имеет смысл в этом порядке - сначала устройство, потом эксплуатация.
Тегированный кеш и композитный сайт - разные названия одного и того же уровня?
Нет, у них разная гранулярность и разный триггер сброса. Тегированный кеш - это точечная инвалидация: конкретная запись помечена тегом, и доменное изменение (например правка элемента инфоблока) сбрасывает только записи с этим тегом. Композит кеширует всю страницу целиком и обновляется по-другому - по времени и по контрольной сумме содержимого, а не по явному тегу. Они работают на разных уровнях пирамиды кеша и обычно применяются вместе, а не вместо друг друга.
Встроенный нагрузочный тест монитора производительности - то же самое, что нагрузочное тестирование перед релизом?
Похожи по инструменту, но не по назначению. Тест «Масштабируемость» в мониторе производительности - это быстрая прикидка прямо на своём сервере, встроенная в тот же модуль, что считает остальные отчёты. Полноценное нагрузочное тестирование перед релизом - процесс из раздела «Инфраструктура»: расчёт нагрузки по реальным данным, генератор нагрузки, сопоставление клиентских и серверных метрик с заранее заданными критериями. Для регулярной проверки одного сервера достаточно первого, для проверки перед серьёзным релизом нужен второй.
Связанные разделы
- Компоненты и шаблоны - устройство композитного сайта и кеш результата компонента, на которые опирается эксплуатационная часть этого раздела.
- Инфоблоки и данные - типичный источник запросов в цикле и тегов инфоблочного кеша, о которых идёт речь в статьях уровня кода.
- Ядро D7 - ORM-выборки, которые чаще всего требуют оптимизации, и события, которыми сбрасывается тегированный кеш.
- Инфраструктура - настройка веб-сервера и базы, на которую опирается пятый, инфраструктурный уровень оптимизации.