Параметры url при которых не будет работать композитный режим

Тонкости композитного режима в 1C-Bitrix

В данной статье я не буду описывать всю технологию, ибо документация по ней присутствует, а отмечу только те моменты, с которыми, по моему мнению, могут возникнуть трудности или непонимание на начальном этапе.

Голосование компонентов

Наверно вы уже видели в шаблонах разных компонентов такую строку:

Так вот, данная функция ничего не включает и не отключает, она только «ГОЛОСУЕТ» за или против использования композитного кеширования на странице, где находится компонент. Это значит, что если в зависимости от настройки композитного режима в админке, а именно опции «Голосование шаблона компонента по умолчанию» (может быть «За» или «Против») и учета голосов всех компонентов на странице, композитный режим кеширования на данной странице будет включен или выключен. При этом, если в админке по умолчанию установлено «Против», то чтобы композитный режим был включен, за него явно должны проголосовать все компоненты.

Динамические области внутри шаблонов компонентов

Динамические области, т.е. те фрагменты html-кода, которые будут подгружены Ajaxом после загрузки закешированной страницы, выделяются в шаблоне компонента при помощи $this->createFrame()->begin(). При этом, есть несколько вариантов их использования, в зависимости от указания параметров как у createFrame, так и у begin.

В первом параметре createFrame указывается DOM идентификатор контейнера, в который будет подгружена динамическая область область после загрузки закешированной странице. При этом во втором параметре следует указать false.

При этом после $frame->beginStub() указывается html-код «заглушки», т.е. тот html, который будет показан до того, как будет подгружена динамическая область. $frame->beginStub() указывать необязательно, можно указать html код заглушки в первом параметре функции begin (а если заглушка не нужна, то в этом параметре при отсутствии $frame->beginStub() следует указывать пустую строку):

Отмена композитного кеширования

Отменить композитное кеширование в любом месте страницы можно с помощью следующей инструкции:

Тестирование

О том что композитный кеш на странице работает (точнее, что страница загружена из композитного кеша) можно судить одним из двух способов:

1. По наличию ссылки «Быстро с 1С-Битрикс», которая появится внизу страницы, если соответствующая ссылка разрешена в настройках композитного кеша (позицией данной кнопки на странице также можно управлять с помощью специального div-контейнера).
2. С помощью расширения «Bitrix Composite Notifier» для браузера «Google Chrome». Если страница идет из композитного кеша, иконка расширения становится цветной вместо серой, и при нажатии на иконку будет отображаться дополнительная информация.

Имейте в виду, что для того, чтобы страница начала отображаться из кеша, как правило нужно перезагрузить страницу 2 раза после первого ее открытия.

Для отладки можно включить лог композитного кеша. Если, например, какой-то компонент голосует против композитного кеша, записи в логе помогут определить какой и т.д. Включить лог можно так:

Сброс кеша при помощи api

Сброс композитного кеша вручную производится на той же странице админки «Настройки кеширования», на которой производится сброс орбычного (не коспозитного кеша). А вот у удалениея кеша при помощи api существуют некоторые особенности.

Если необходимо удалять кеш по расписанию, то не рекомендуется просто удалять содержимое папки /bitrix/html_pages/домен/. Хотя можно поступить и так, удалив при этом также содержимое файла /bitrix/html_pages/.enabled, но в этом нет необходимости, т.к. в системе уже существует специально созданный файл /bitrix/modules/main/tools/cron_html_pages.php, запуск которого можно осуществлять из под крона. Например, следующая команда запустит удаление файлов композитного кеша, которые были созданы ранее чем 10 часов назад:

Также можно удалить композитный кеш при помощи api:

Источник

Подключаем Композит

В этой небольшой заметке рассмотрим процесс подключения технологии Композитного сайта в проектах на 1С-Битрикс.

Сразу пару ссылок на описание технологии, на всякий случай:

Что имеем перед началом внедрения:

• магазин на БУС 17 с рядом подгружаемых ajax-ом областей;
• Bitrix VM 7, PHP 7;
• VPS на SSD;
• кеш хранится в memcached;
• конфигурация оптимальна;
• монитор производительности радует;
• клиент доволен.

Казалось бы, ну что ещё?

И тут раздаётся голос Внутреннего Перфекциониста: «Хочу быстрее, сделай быстрее, хочу, хочу, сделай.»

Какое-то время можно и пожить с этим тихим вкрадчивым укором. Композит — не то, что надо бросаться делать в первую очередь, тем более, если проект в целом работает без сбоев.

Но однажды понимаешь, что можно просто взять и сделать. Иначе голос не успокоится. Печенька комом, смузи безвкусен, панкейк не торт.

Давайте рассматривать сразу правильный вариант — у вас есть тестовая копия проекта, прикрытая снаружи. Если нет — сделайте. Не можете сделать — работайте по-живому, бог простит, клиент не увидит. Шутка. Просто сделайте копию. Для начала идём в админке тестовой копии в Настройки → Настройки продукта → Композитный сайт и недрогнувшей рукой решительно и бесповоротно включаем Автокомпозит. После чего начинаем методично и внимательно тестировать все интерфейсы сайта, моделируя выдачу под разными пользователями. В первую очередь обращаем внимание на поведение блоков, перерисовываемых аяксом, без обновления страницы. С вероятностью, близкой к 100%, ряд блоков будет работать некорректно. Причина проста, она кроется в самой технологии. Композитный кеш — это логическое продолжение старой технологии html-кеширования, без «обучения» кешированный контент создаётся по первому хиту первого пользователя и затем транслируется всем остальным пользователям. Поэтому вполне возможна, например, ситуация, при которой всем пользователям будет показываться «первая созданная» кем-то маленькая корзина — одна и та же для всех. Или, к примеру, все будут видеть «авторизацию» какого-то другого пользователя. Авторизация тут взята в кавычки, т.к., конечно, никто реально не авторизуется под этим пользователем, а будет отображаться, к примеру, приглашение войти в личный кабинет под ним (технически говоря, сгенерированный при авторизации этого пользователя html-код блока, транслируемый затем всем остальным).

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

В отладке нам помогут: константа BX_COMPOSITE_DEBUG со значением true в файле /(bitrix|local)/php_interface/dbconn.php (не забудьте отключить после отладки!) и расширение для Google Chrome Bitrix Composite Notifier. В режиме отладки используется системная функция AddMessage2Log, которая пишет в лог запись, если какой-то шаблон компонента голосует «против» (для работы функции нужно установить константу LOG_FILENAME со значением в виде полного пути к файлу лога). Прописывем константу, или в конкретной странице, или глобально, устанавливаем расширение и начинаем анализировать.

Под анонимным пользователем просматриваем все страницы сайта, которые должны быть «композитными». В нормальном случае иконка расширения в браузере должна быть активной (цветной).

Если на какой-то странице иконка неактивная (серая) — технология на этой странице не работает и необходимо разобраться.

Здесь нам и поможет файл лога. Открываем его, смотрим, какие же шаблоны голосуют «против», и адаптируем их под композитный режим. Продолжаем до тех пор, пока на всех интересующих страницах не будет «гореть» индикатор расширения. После этого нужно убедиться, что весь контент, который должен быть уникальным для каждого пользователя, подгружается в фоновом режиме, а не кешируется вместе со статикой. Обычно это малая корзина пользователя, блок авторизации, количество товаров в избранном и т.п. На этом этапе всю динамику выносим в динамическую часть, при необходимости делаем заглушки. Намеренно не описываем тут сам процесс адаптации с точки зрения программирования, т.к. он подробнейшим образом изложен в букваре, да и речь в данном случае больше об организации процесса перехода, нежели о коде компонентов.

Если всё хорошо и страницы начали отдаваться из кеша, стоит удостовериться, что кеш живет достаточно долго и не перезаписывается на каждом хите. Такое вполне может быть, если в заглушках или «статичном» контенте используются динамические данные. Например, в шаблоне, обозначенном как статичный, прописан вывод функции time() в шаблон. Мало ли, психанул кто-то. Выявить такие страницы достаточно просто. При включенном режиме отладки (BX_COMPOSITE_DEBUG) в папке кеша /bitrix/html_pages// файлы перед перезаписью копируются в файлы с расширением *.delete.. Если таких файлов много, то есть смысл пробежаться по ним, выявить различия и оптимизировать код, который эти различия создает. По возможности избавляемся от таких участков в коде или заменяем их JS-вариантом.

После того, как компоненты подготовлены к работе с Композитом, можно и нужно перенести код на боевую версию сайта. На боевом Композит пока не включаем. Опять тестируем работу всех интерфейсов, если всё сделать правильно, код будет одинаково работоспособным при любом типе кеширования. Правильно работает? Убедились? Точно? Ещё раз проверили? Ну ок, верим, давайте кнопочку нажимать. Скидываем кеш в настройках, включаем Автокомпозит и ещё раз всё проверяем. Не забыли указать все домены сайта в настройках Композита? Молодцы. Открываем сайт в режиме «инкогнито», жмём F12 и пару раз жмём F5. Именно пару раз. На первый хит страница будет отдана сервером «как обычно», при этом будет создан композитный кеш, по второму хиту сервер отдаст созданный композитный кеш и получит директиву «вот теперь его показывать». И на третий хит мы получим страницу с «полным применением» Композита. Если всё работает как надо, во вкладке Network отладчика будет примерно такая картина:

Как видим, документ мы получаем со статусом 304, т.е. страница не изменялась, а ресурсы берутся из кеша. При этом у нас продолжают функционировать интерактивные элементы интерфейсов. Можно потеребить F5 и насладиться скоростью.

Ну и напоследок, как водится, небольшая ложка дёгтя ко всей этой красоте.

По умолчанию композитный кеш хранится в файлах. Если использовать BitirxVM, хостинг на базе этой виртуальной машины, пакет веб-окружения от Bitrix или у вас достаточно прямые руки, чтобы соорудить нужный конфиг самостоятельно — кеш будет отдаваться Nginx-ом, без запросов к бэкенду.

Соответственно, в заголовках ответа будет: X-Bitrix-Composite: Nginx (file). Это уже хорошо и уже быстро. Но если стараться делать совсем правильно (опять этот голос. ), логично было бы «переселить» композитный кеш в memcached, т.е. хранить его в разделяемой памяти, что, конечно же, даст ещё прирост скорости, особенно, если сервер на обычном HDD. И вроде бы это всё должно заработать «из коробки», но увы. На данный момент (апрель 2017 года) переключение типа хранения в настройках Композита в админке на memcached и затем обновление конфига Nginx через панель управления BitrixVM полноценного результата не дадут. Если memcached подключен по обычной схеме, через порт, вы получите заголовок X-Bitrix-Composite: Nginx (memcached), т.е., на первый взгляд, правильный, но страница всё равно будет каждый раз отдаваться сервером со статусом 200 OK, а не 304 Not modified, т.е. грузиться заново. А мы-то хотели добиться 304 статуса, чтобы документ без изменений собирался из кеша браузера, не тратя время на получение тела документа с сервера. Если же попробовать подключить memcached через unix socket, Nginx с ним вообще работать не будет, будет пропускать всё «насквозь» и в заголовке будет стандартный X-Bitrix-Composite: Cache (200). Т.е. да, Композит-то включён, кеш есть, но «за ним надо ходить к бэкенду», что, скажем уклончиво, несколько обесценивает суть технологии. Техподдержка Битрикса об этих нюансах знает и обещает исправить, так что пока используйте хранение в файлах в связке с Nginx в BitrixVM.

А этого, Внутреннего своего, не слушайте, лучше печенькой его покормите.

Источник

Композитный режим Битрикс

Композитный режим — технология ускорения сайта, которая применяется на движке 1С Битрикс. Он позволяет отображать страницу пользователю за 0.1 — 0.5 секунды.

Преимущества композитного режима

В некоторых случая при значительных поломках сайта (например ошибках в коде, потери доступа к базе данных), сайт продолжает работать.

Недостатки композитного режима

Неправильной настройкой композитного режима можно увеличить скорость отклика сайта и понизить позиции сайта в поисковой выдаче!

Обращайтесь к квалифицированным специалистам. Мы настроим композитный режим с гарантией правильной работы!

Хотя композитный режим в Битриксе есть уже не первый год, на мой взгляд, технология ещё «сыренькая» и требует доработок.

Также из недостатков отмечу, что режим иногда ломается (чинится периодической чисткой кэша), может занимать дополнительное место на сервере. При включении технологии сайт начинает иметь некоторые особенности — обновлять информацию на втором обновлении страницы.

Композитный режим, примеры сайтов

http://www.vestnik-evropy.ru/
Информационный сайт. Обратите внимание на скорость отображения страницы при переходе с раздела на раздел

http://www.tochkarosi33.ru/
Современный дизайн, Маленький интернет магазин окон. А как быстро грузится?

https://sait-optimize.ru/
Мой сайт является композитным. Я специально оставил значок внизу страниц чтобы показать что технология включена и работает

Настройка композитного режима

В этой статье я опишу по шагам как настраивается композитный режим сайтов на движке «1с Битрикс». Почитав курсы далеко не сразу разберёшься как же настроить это чудо инженерной мысли, да и вообще что это за этакое чудо «композитный режим«.

Только настроив его первый раз, я сам убедился, что технология действительно очень крутая и полезная для всех, а для пользователей сайта в первую очередь!

Шаг 1. Включаем композитный режим в админке Битрикса

Заходим на наш сайт, авторизуемся под админом. Переходим в раздел Настройки > Настройки продукта > Композитный сайт . Нажимаем кнопочку «Включить композитный режим»

Шаг 2. Настраиваем лог композитного режима

Необходимо включить лог композитного режима и разрешить в него запись. Заходим на сервер и редактируем файл /bitrix/php_interface/dbconn.php. Добавляем туда две строчки (если их нет). В этих строчках определяются две константы php:

После этих действий нужно выбрать любую, желательно простенькую, страницу сайта на которой будет настраиваться композитный режим. Заходим на нашу страницу сайта. Открываем создавшийся файлик с логом /log_composite.txt и убеждаемся что туда что-то записалось. Какой-то текст в логе означает что мы на правильном пути.

Шаг 3. Выводим значок Битрикса на страницу

Нужно выбрать место на странице, куда будет выведен значок Битрикса. Как известно, шаблон страницы делится на header и footer. Для примера предлагаю вывести в footer. Открываем /bitrix/templates/название шаблона/footer.php и добавляем в то место куда нужно вывести значок вот такой див:

Обновляем нашу страницу пару раз и видим что действительно, значок выводится в том месте где мы его поставили.

Настроить внешний вид значка Битрикса можно в том же разделе Настройки > Настройки продукта > Композитный сайт во вкладке «кнопка».

Если значок не появился, это означает что композитный режим не работает и нужно искать причину неисправности.

Причины могут быть разные.

Теперь самое время включать голову и разбираться с теорией. А из теории в документации собственно пара основных пунктов, если выбросить всю прочую ерунду.

Теория тезис 1. Общая схема работы композитного режима

При запросе пользователя система собирает html-страницу, сохраняет её на сервере в виде файла (кэш) и при обращении к этой странице отдаёт сохранённую (закэшированную) страницу. Причём после отдачи кэша, система выполняет php скрипты, собирает запрашиваемую страницу, сравнивает её с кэшем и если есть различие хотя бы в одном символе, система перезаписывает кэш.

Так происходит каждый раз при запросе любой страницы сайта.

Теория тезис 2. Понятия «статическая» и «динамическая» области в композитном режиме

Вызываемая пользователем страница имеет статические и динамические области. Эти термины в контексте композитного режима должны восприниматься не как стандартные понятия. Здесь понятие статическая область означает область на странице, которая при перезагрузке страницы остаётся в точности такой же как и до перезагрузки. Если какой-то контент на странице изменяется каждый раз, то такая область считается динамической.

Композитный режим позволяет существенно ускорить скорость загрузки страницы, но он также имеет небольшой недостаток. По сути здесь палка о двух концах — всё что включается в статическую область показывается пользователю сразу, кроме того, только статическая область индексируется поисковыми системами. Динамические области подгружаются на страницу после того как они будут вычислены и не принимают участия в индексировании роботами.

Шаг 4. Настройка голосования компонентов

Как известно, шаблон сайта имеет компоненты, поэтому для определения всей статической страницы (кэша) каждый компонент должен проголосовать «за» включение его в статическую часть, либо «против».

Если компонент голосует «за» — это означает, что выводимый компонентом текст каждый раз одинаковый и не меняется. Для голосования компонента в самом начале его шаблона нужно прописать следующую строчку:

Если же компонент голосует «против» — это значит что при каждой загрузке страницы возвращаемый компонентом текст разный. Для голосования компонентом «против» включения его в кэш, в самом начале его шаблона нужно прописать такую строчку:

Причём слово «Загрузка» будет отображено сразу на странице в том месте где должен отработать шаблон компонента. Как только сервер вычислит текст который должен быть на месте шаблона, он подставит этот текст вместо слова «Загрузка».

Кроме этих двух состояний шаблон компонента может использовать смешанный режим — статическая область с динамическими вставками. В таком случае сам шаблон по умолчанию считается статическим. Для определения динамической зоны нужно прописать код:

В некоторых случаях приходится объявлять динамические зоны вне компонентов. В этом случае используется следующий код:

Советы по отладке

Алгоритм действий по отладке композитного режима следующий:
1. выбираем нужную страницу
2. определяем все расположенные на ней компоненты
3. «голосуем» шаблонами компонентов «за» или «против» включения в статическую область
4. определяем возможные зоны в шаблоне сайта, которые могут быть включены в динамическую область
5. открываем страницу в браузере(при этом нужно быть не авторизованным пользователем на сайте), обновляем страницу пару раз
6. чистим лог композитного режима (открываем файл лога, удаляем от туда всё что есть, сохраняем, закрываем файл)
7. возвращаемся к браузеру, обновляем пару раз страницу
8. смотрим лог, находим ошибки, устраняем их, пункт 6, пункт 7, пункт 8 и т.д. до полного устранения ошибок

Если при работе композитного режима произошла ошибка, то значок Битрикса не будет показан и в лог запишется например следующее:

Означающий что указанный компонент не проголосовал «за» или «против» включения шаблона в статическую часть.
Или например вот такая информация:

Последний момент которых хотелось бы отметить — если у Вас при каждом хите происходит перезапись кэша, то это не правильно, т.к. каждый раз тратится время на запись в файл и происходит загромождение диска сервера, композитный режим увеличивает время загрузки страницы. В этом случае нужно ещё раз внимательно просмотреть две загруженные страницы, определить символы в которых они различаются и подумать как устранить этот дефект.

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

• Включите логирование композитного режима (в лог-файл должна писаться информация)
• Почистите кэш
• Пересохраните настройки композитного режима с разными параметрами
• Очистите куки браузера
• Проверьте нет ли GET параметра ncc равного 1
• Тот ли домен стоит в настройках композитного режима
• Обновите систему до последней версии

Услуги по настройке композитного режима

Примерно с версии 17.0. Битрикс сделал «автокомпозит» и заявил что технология теперь настраивается без помощи программиста (очень хотелось бы верить). Однако до этой версии композитный режим настраивался руками. Если ваш сайт имеет версию до 17.0, то стоимость настройки будет от 5000 рублей (в зависимости от объёма сайта). Если нужно проверить правильность работы композитного режима, или как-то донастроить его, то стоимость услуг можете узнать у меня.

Источник