Особенности композитного режима

Технология «композитного сайта» в ряде случаев способна в значительной мере снизить время отклика тяжёлых сайтов созданных на базе CMS семейства Битрикс. На время отклика влияет целый комплекс различных факторов, таких как: конфигурация ОС, TCP/IP-стека, производительность ОЗУ, дисковой подсистемы, используемой СУБД, самой CMS 1C-Битрикс, географическое расположение сервера, использование современных протоколов передачи данных (HTTP/2), криптографических алгоритмов (SSL/TLS) и многое другое. Использование композитной технологии не является «серебрянной пулей» способной отменить их влияние. Однако, она позволяет нивелировать время отклика страниц сайта сделав его более усреднённым.

Предположим, мы имеем заглавную страницу сайта с использованием десятка компонентов типа lists, news, form, search и др. И страницу «Контакты» на которой кроме адреса компании ничего более нет. Очевидно, что время отклика этих страниц будет различаться в разы. Будет затрачено время на множественные обращения к API и СУБД, а они являются наиболее прожорливыми по отношению к ресурсам и выполняются web-сервером индивидуально (в данном случае) для каждого посетителя нашего сайта.

Как это работает

Композитная технология позволяет отдавать посетителю предварительно сформированные HTML-страницы. Это снижает нагрузку на web-сервер т.к. его ресурсы на интерпретацию PHP-кода, обращения к API и СУБД будут затрачены однократно, при формировании страницы.

HTML-страницы формируются для каждой страницы сайта и каждого домена на web-сервере (например, www.domain.tld и domain.tld – разные домены) и представляют собой «каркас» содержащий только статический контент. Области динамического контента должны быть заранее заданы в шаблоне сайта и обновляются AJAX-скриптом после того как web-сервер страницу уже отдал. Со стороны пользователя это выглядит как открытие всей страницы сайта сразу, с последующей дозагрузкой некоторых её частей (например, баннеров, карточек товаров, списков и т.д.). Во время загрузки динамического контента на странице пользователю можно показывать анимацию или вывести надпись «Пожалуйста, ожидайте», «Идёт загрузка» и т.п.

Композитный сайт выигрывает за счёт повышения отзывчивости и ориентированности на клиента, пропорционально увеличивая время пребывания посетителей на сайте. Но в ней имеются и свои «камни преткновения». Типичной является ситуация когда композитную технологию пытаются включать без адаптации шаблона. В этом случае при выполнении посетителем действий на странице, никаких изменений происходить не будет, а посетитель будет получать ранее зафиксированную страницу.

Композитную технологию не стоит путать и с простым кэшированием, поскольку помимо этапа кэширования, существует этап формирования страницы в котором задействовано API Битрикс. Сама же идея предварительной подготовки данных предоставляемых пользователю известна программистам с середины прошлого века.

Как это использовать

Композитная технология стала доступной массовому пользователю начиная с Битрикс версии 14.5 появившейся в 2014 г, но и сегодня количество композитных сайтов в рунете невелико. Сухой и консервативный стиль официальной документации, её неполнота и разрозненность, использование собственной терминологии вызвали взрывной рост статей на тему внедрения, но увеличения числа сайтов использующих композит не произошло.

Рассмотрим некоторые типовые проблемы.

• Композитный режим работает «через раз»

Это не проблема, это – нормально. На первом хите создаётся HTML-страница, она записывается в директорию /home/bitrix/<сайт>/bitrix/html_pages/<домен>/.html и на втором хите посетителям будет отдаваться уже она.


• Непонятно работает композитный режим или нет

1С-Битрикс предусмотрели для теста специальный баннер. Он включается галкой в «Настройки продукта > Композитный сайт > Кнопка “Быстро с 1С-Битрикс”». Увидеть его можно на DEMO-сайтах. А мы этот баннер увидим только при условии что где-то в шаблоне указано:

<div id="bx-composite-banner"></div>


• Непонятно какая страница композитная, а какая требует адаптации



Удобней всего это проверять в Google Chrome. Для этого потребуется установка двух лёгких расширений: Bitrix Composite Notifier и Page load time. Первое показывает этап работы композитного режима и возвращаемые web-сервером заголовки характерные для Битрикс, второе - реальное время отклика в браузере. Заголовки целиком удобно читать вызывом:




wget --server-response -O /dev/null




Для второго хита будет характерно появление заголовка X-Bitrix-Composite



• Бесконечно создаются страницы и место на диске сервера заканчивается



Композит не создаёт страницы бесконечно, но многообразие страниц сайта кэшируемых вместе с передаваемыми им параметрами поистине безгранично. Вы можете сохранять на диск страницы без параметров установкой соответствующей галки в «Настройки продукта > Композитный сайт > Настройки». Но более разумным будет перечислить неиспользуемые параметры в «Игнорировать следующие параметры URL». Например, это могут быть параметры личного кабинета.



• Директория html_pages занимает слишком много места

Размер директории html_pages порядка 512M совершенно нормален. Но вряд ли нам нужны страницы которые были созданы год назад и к которым больше не возвращались. Для удаления файлов композитного кэша созданного ранее чем 10 часов назад добавьте в /etc/crontab web-сервера следующую строчку :



0 */11 * * * bitrix php -f /home/bitrix/<домен>/bitrix/modules/main/tools/cron_html_pages.php 10 >/dev/null  2>&1

На чём это запускать

Среда BX-Env 5.1.9 не поддерживает работу в CentOS 7, но если нет необходимости в предоставляемых ей скриптах поддержки и пакетах (ansible, nrpe, munin, sphinx, etckeeper, msmtp, sar и др.), то нижеприведённые рекомендации позволят настроить (по аналогии) производительный композитный web-сервер и на CentOS 7.1.

Без среды BX-Env, в числе прочего, мы лишаемся скриптовой поддержки Веб-кластера Битрикс, однако считаем это незначительной потерей. В общем случае рекомендуем использовать хорошо документированный и совместимый с BX-Env дистрибутив CentOS 6.8

Как это запускать

1. Обязательным является включение gzip-сжатия для всех значимых mime-типов файлов конкретного сайта. Меньше трафик – ниже время отклика (пропорционально сжатию). Значительно загрузить процессор таким образом не получится, но при высоком ratio ощутимо увеличится время необходимое для сжатия трафика «на лету». Здесь необходимо находить баланс индивидуально для каждого сайта.


2. В тех случаях когда предполагается что основной домен сайта будет работать по HTTPS, логичным является включение протокола HTTP/2 штатно поддерживаемого в nginx начиная с версии 1.10 (экспериментально с 1.9.5). При этом не будут работать некоторые старые браузеры, но прирост производительности виден даже на глаз.


3. Настройка LAMP как nginx (frontend) + httpd (backend), является общепринятой, но морально устаревшей практикой. Это давно признано разработчиками 1С-Битрикс. Более производительной является связка nginx + nginx, либо nginx + php-fpm. Мы пойдём по второму варианту.


4. Композит не является основным средством снижения времени отклика сайта, но оказывается вполне эффективным подспорьем. В среде BX-Env его поддержка «размазана» между конфигурациями httpd и nginx. Коль скоро мы заменяем httpd на php-fpm в LAMP, нам потребуется воспроизвести всю логику работы композитного кэша (на 90% полагающегося на nginx) в нашем nginx.conf. Помимо настройки и включения поддержки композита необходима обязательная доработка шаблона сайта.


5. Два основных локомотива разгоняющих PHP: php-fpm и ZendOpcache. Первый управляет PHP-процессами и должен соответствовать выбранной версии PHP, а второй не должен кэшировать лишний байт-код (для этого у него должны быть настроены исключения).


6. Из популярных акселераторов PHP адекватно (параллельно с ZendOpcache) работает только memcached. Однако, на практике виртуализованный 1С-Битрикс с memcached проигрывает такому же 1С-Битрикс с файловым кэшированием. Во всех случаях наблюдается, напротив, пессимизация. Несколько увеличить производительность memcached позволяет работа через сокеты. Без плотной поддержки в коде memcached и вовсе бесполезен.


7. Битрикс начиная с версии 16.5 поддерживает PHP 7.0 в основных компонентах. Это (в некоторых случаях) даёт ощутимый прирост производительности. В некоторых не даёт ничего. Мы будем использовать стабильную версию PHP 7.0.14, не старше (старше не работает).


8. Существенной проблемой для 1С-Битрикс являются чрезвычайно неадекватные запросы к СУБД генерируемые API. Их можно увидеть в slow.log или (с большим удобством) в Anemometer. Поскольку поддержки Oracle и PostgreSQL в 1С-Битрикс пока не предвидится, при всём богатстве выбора самым эффективным является использование Percona Server. То же самое рекомендуется и самой компанией Битрикс.


9. Percona Server позволяет использовать более эффективную подсистему хранения данных – XtraDB. Она оптимизирована для сред с высокой производительностью. Также как и в случае с InnoDB мы можем разместить всю БД в памяти (innodb_buffer_pool_size). Мы можем хранить таблицы в раздельных файлах (innodb_file_per_table). В файловом формате Barracuda (innodb_file_format). Эти и другие оптимизации Percona позволяют существенно снизить время отклика сайта.


10. Если ресурсы позволяют, нагрузку можно распределить. В минимальном варианте это должны быть 3 ноды Galera Cluster с multi-master-репликацией. Производительность такого решения по чтению/записи вполне приемлемая. При дальнейших инвестициях в кластер могут добавляться балансировщик и slave-ноды.