Битрикс ошибка не кэшированное меню

Всем привет

Настроил композитный сайт для интернет-магазина в автоматическом режиме и в настройках установил:
Перезапись кэша — стандартный режим (без задержки по времени);
Механизм хранения — memcached;

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

Если установить задержку, то естественно все работает нормально. Но по истечению срока кэш все равно будет перезаписан, несмотря на то, что контент фактически не менялся.

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

На большинстве страниц фиксирует такие изменения:

<button class="open_list fa fa-angle-down visible-xs" data-id="cat_mobile_DHD"></button> <!-- for mobile -->
</div>
<ul class="bx-nav-list-3-lvl hidden_list" id="cat_mobile_DHD">

<button class="open_list fa fa-angle-down visible-xs" data-id="cat_mobile_5Bl"></button> <!-- for mobile -->
</div>
<ul class="bx-nav-list-3-lvl hidden_list" id="cat_mobile_5Bl">

</body>
</html>
<!--658042558a7bfec9a36ab43cee4a9940-->

</body>
</html>
<!--4e07ddc52276c4d1fa429ce3bcf67744-->

В панеле производительности, в разделе разработки выводит ошибку «1-й тип не кешированное меню» и на некоторых страницах дополнительно выводит «2-й тип: не кешированные компоненты.
bitrix:sale.basket.basket.line»

Как это исправить?

P.s. подскажите, пожалуйста, оптимальные настройки кэширования для небольшого интернет-магазина (600-700 наименований), хостинг reg.ru. В ispmanager настроено сжатие (уровень 5) и кэширование (7 дней). Нужно ли изменить?
Нужно ли дополнительно прописывать директивы в htaccess и что это дает?
Сколько памяти выделить под memcached? ОЗУ 2гб, сейчас выделено 64мб.

Не работает кеширование на сайте

Кеширование включенно и вадминке и у компонентов, но всегда Cache size: 0 b
Папка /bitrix/cashe/ пустая
В панели производительности Хранение кеша: cacheenginenone

Может быть cacheenginenone причиной проблемы?

С этим все в порядке

Про это мы в курсе, проблем там нет

Проблему решили на сервере.

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

Короче, cacheenginenone горит когда у вас некорректно настроен сам софт. Например, вы указали хранение в мемкеше, а мемкеш не настроен, не заводится. Тогда проект НЕ БУДЕТ кешироваться, а в панели будет гореть «cacheenginenone», что своего рода болванка по умолчанию.

А вы случайно не сталкивались с ситуацией, когда 2 сайта работают на одной копии 1С-Битрикс, но при проверке производительности в админке первого сайта выводится cacheenginenone, а при проверке производительности в админке второго сайта выводится memcache ?

Причем, я вношу изменения в файлы .settings.php и .settings_extra.php касательно кеширования и значение в панели производительности меняется в админке второго сайта, но в админке первого сайта, не смотря ни на что, постоянно висит cacheenginenone.

P.S. Оказалось, дело было в версии php, которая должна была быть 5.3, а на первом сайте стояла 5.4.

Хостинг timeweb.

та же история с таймвебом, плановый переход выполняю всех сайтов с 5.3 на 5.4.
в процессе выяснилось что в 5.4 не работают основные настройки которые прописывались ранее в блоке .htaccess
касательно кодировки, pcre.recursion_limit итд

в итоге общения с техподдержкой выяснилось что надо теперь их прописывать в папке cgi-bin в корне сайта в файле php.ini

В ходе проб и ошибок родилась примерно такая структура данного файла

каждая строчка по сути убирает одну и ошибок которую выдаёт битрикс при проверке конфигурации, либо при запуске сканера безопасности.

Источник

Не работает кеширование компонентов на странице

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

1. Автокеширование компонентов включено .
2. Управляемый кеш компонентов включен .
3. Кеширование HTML выключено .
4. В настройках стандартного компонента bitrix:news.list:

• Тип кеширования: авто+управляемое
• Время кеширования (сек.): 3600

Используется php 5.3.16 + wincache.

Как выяснить причину?

фильтр на странице есть,
проверял, когда выражение фильтра пустое, на индексной странице раздела,
кликая каждый раз по соответствующей ссылке на раздел из меню

общий ужас выглядит так:

У вас в юрле, случайно ckear_cache=Y не установлен?

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

Детальный анализ выявил проблемы в работе wincache
тех.поддержка заявила о нем как «не гарантируется поддержка» и рекомендовала перейти на APC, Xcache
Apc не удалось подружить с многопоточным IIS, в рузальтате данные хоть и кешировались, но страница выдавалась со значительной задержкой
Xcache вместе с IIS 7 показал себя неплохо, на нем и остановился

возник некий глюк с Xcache
компонент bitrix:news.list содержит в себе другой нетиповой компонент , кеш работает нормально — без запросов. но стилевое оформление вложенного компонента сбивается. На уровне html в коде страницы с и без кеширования различий не заметил.
будем разбираться дальше.

Может кто уже знает ответ на вопрос проблемы со стилями при кешировании.. ?

Источник

Особенности кеширования компонентов

«Мы сделали свой компонент, но при включении автокеширования он работает неправильно. Исправьте механизм кеширования.»

Мне часто приходится слышать о такой проблеме. Аналогичная проблема возникает со своими шаблонами компонентов. Ситуация обычно усложняется тем, что техподдержка отказывается решать проблему ссылаясь на то, что стандартные компоненты системы работают нормально.
Предлагаю окончательно разобраться в этом вопросе и расставить все точки над «i».

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

Автокеширование появилось в 6-й версии продукта для замены стандартного кеширования компонентов. Единственное отличие в том, что автокеширование может выключаться глобально на весь сайт одной кнопкой в админке. Т.е. на этапе разработки оно выключено, перед сдачей проекта включается и, условно говоря, всё полетело!

Устройство и место хранения

Кеш компонентов хранится в файлах в папке /bitrix/cache .
На основе следующих параметров формируется идентификатор кеша компонента:

• ID текущего сайта,
• имя компонента,
• имя шаблона компонента,
• параметры компонента,
• внешние условия, которые определяются в компоненте (например, список групп, к которым привязан текущий пользователь).

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

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

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

Структурная схема работы компонента

В $arParams содержится набор параметров компонента, component.php работает с входными параметрами запроса и базой данных, формирует результат в массив $arResult .
Шаблон компонента преобразует результат в текст HTML .

При первом хите сформированный HTML попадает в кеш (здесь и далее операции чтения показаны синими стрелками, записи — красными).

Пунктирная линия показывает порядок обработки php кода.

При последующих хитах работает другая схема:

Запросов в базу не делается (или делается мало), данные читаются из кеша.
Ключевой момент: порядок выполнения, в этом случае код шаблона компонента и result_modifier.php не исполняются .

Популярная ошибка, в шаблоне компонента вызываются отложенные функции: $APPLICATION->SetTitle(), $APPLICATION->AddChainItem() и т.д. В этом случае они работают только при выключенном кешировании.

Периодически приходится наблюдать картину: хостер отключает аккаунт за большую нагрузку на сервер, клиент обращается к нам в техподдержку, мы видим, что кеширование компонентов не используется. Клиент объясняет это так: «мне сказали ваши партнёры разработчики компонентов, что для этого компонента нельзя включать кеширование т.к. оно в битриксе криво работает».

При разработке шаблонов надо следовать простому правилу: задача шаблона — на основе входного массива $arResult сформировать текст HTML на выходе.

Источник

Проблема с меню, кэш ?

Подскажите, в чем может быть проблема.
С недавнего времени меню, bitrix:menu , начало «пропадать», вчера было, сегодня пусто! Причем пункты меню тоже изчезают и ессесьно становятся не кликабельны .
Я сразу в осадок давай выпадать . Разработчики посоветовали кэш удалить — удалил, не помогло.
По сути мне нужно зайти в админку, обновить кэш кнопкой, появляется меню . и так для каждого раздела меню — бред!

В чем может быть проблема?

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

Но проблему то это не решает, ибо заходишь в новость_1 — там меню не отображается, обновил кеш — отображается;
Заходишь в новость_2 — опять меню нет.
И вот так обновлять все новости? У меня их пока тестовых штук 10, а когда запустим сайт и новостей скажем будет 500 — это умом тронешься быстрей, чем обновишь все

Вот знаешь, же пришел к такому же выводу.

Вопросы на самом деле остались .

Менюшка не появляется, если самолично не обновить кэш кнопкой .

Так же интересна кнопка «Учитывать права доступа», т.е. как контент-манагер обновил кеш — для него она обновилась, а для всех остальных — нет ?
«Время кеширования (сек.): 3600» — вот что это значит ? Время обновления данного компонента ? Т.е. каждые 3600 секунд данный компонент будет обновляться ?

Источник

Битрикс — проблемы с кэшированием

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

belvederupak.ru/catalog/1/46/ вот каталог продукции, сделан он на инфоблоках. — news.detail

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

if ( intval ( $_REQUEST [ «ID» ] ) > 0 ) <

$arSelect = Array ( «ID» , «NAME» ) ; // выборка нужных значений
$arFilter = Array ( «IBLOCK_ID» => 5 , «ACTIVE_DATE» => «Y» , «ACTIVE» => «Y» , «ID» => $_REQUEST [ «ID» ] ) ;
$res = CIBlockElement :: GetList ( Array ( ) , $arFilter , false , Array ( «nPageSize» => 50 ) , $arSelect ) ;
$ob = $res -> GetNextElement ( ) ;
$arFields = $ob -> GetFields ( ) ;
//print_r($arFields);

$title = $arFields [ ‘NAME’ ] ;

$APPLICATION -> SetPageProperty ( «title» , $title . ‘ в Новосибирске по низким ценам. Купить товар ‘ . $title . ‘ оптом от производителя – Бельведер Упак’ ) ;
$APPLICATION -> SetPageProperty ( «keywords» , $title . ‘ оптом и в розницу в Новосибирске. Продажа товаров ‘ . $title . ‘ от производителя – Бельведер Упак.’ ) ;
$APPLICATION -> SetPageProperty ( «description» , $title . ‘ в Новосибирске, ‘ . $title . ‘ купить, ‘ . $title . ‘ цена, ‘ . $title . ‘ оптом, ‘ . $title . ‘ производство ‘ ) ;

$APPLICATION -> IncludeComponent ( «bitrix:news.detail» , «catalog» , array (
«IBLOCK_TYPE» => «belveder» ,
«IBLOCK_ID» => «5» ,
«ELEMENT_ID» => $_REQUEST [ «ID» ] ,
«ELEMENT_CODE» => «» ,
«CHECK_DATES» => «Y» ,
«FIELD_CODE» => array (
0 => «NAME» ,
1 => «DETAIL_TEXT» ,
2 => «» ,
) ,
«PROPERTY_CODE» => array (
0 => «» ,
1 => «PHOTO» ,
2 => «» ,
) ,
«IBLOCK_URL» => «» ,
«AJAX_MODE» => «N» ,
«AJAX_OPTION_JUMP» => «N» ,
«AJAX_OPTION_STYLE» => «Y» ,
«AJAX_OPTION_HISTORY» => «N» ,
«CACHE_TYPE» => «A» ,
«CACHE_TIME» => «36000000» ,
«CACHE_GROUPS» => «Y» ,
«META_KEYWORDS» => «-» ,
«META_DESCRIPTION» => «-» ,
«BROWSER_TITLE» => «-» ,
«SET_TITLE» => «Y» ,
«SET_STATUS_404» => «Y» ,
«INCLUDE_IBLOCK_INTO_CHAIN» => «Y» ,
«ADD_SECTIONS_CHAIN» => «Y» ,
«ACTIVE_DATE_FORMAT» => «d.m.Y» ,
«USE_PERMISSIONS» => «N» ,
«DISPLAY_TOP_PAGER» => «N» ,
«DISPLAY_BOTTOM_PAGER» => «N» ,
«PAGER_TITLE» => «Страница» ,
«PAGER_TEMPLATE» => «» ,
«PAGER_SHOW_ALL» => «N» ,
«AJAX_OPTION_ADDITIONAL» => «»
) ,
false
) ;

В этом же файле — catalog/index.php если $_REQUEST[‘ID’] Не задан, то через if прописано условие вывода инфо о продукции

if ( CModule :: IncludeModule ( «iblock» ) ) <
$arOrder = array ( «SORT» => «ASC» ) ;
$arFilter = array ( «IBLOCK_ID» => 5 , «ACTIVE» => «Y» , «ID» => $_REQUEST [ «SECTION_ID» ] ) ;
$tmpResult = CIBlockSection :: GetList ( $arOrder , $arFilter , false , $arSelect = Array ( ‘UF_TITLE’ , ‘UF_KEYWORD’ , ‘UF_DESCRIPTION’ , ‘UF_H1’ ) ) ;

if ( $ob = $tmpResult -> GetNext ( ) ) <

$APPLICATION -> SetPageProperty ( «title» , $ob [ UF_TITLE ] ) ;
$APPLICATION -> SetPageProperty ( «keywords» , $ob [ UF_KEYWORD ] ) ;
$APPLICATION -> SetPageProperty ( «description» , $ob [ UF_DESCRIPTION ] ) ;

‘ ;
echo $ob [ «UF_H1» ] ;
echo ‘

Источник

С 2015 года мы оказываем официальную услугу «1С-Битрикс» — аудит производительности сайтов. В рамках аудита мы не просто анализируем настройку и конфигурацию сервера, но также просматриваем код: переносим проект к себе на стенд, где изучаем что именно можно изменить в коде и конфигурации компонентов так, чтобы сайт работал быстрее. 

Однако вначале давайте поговорим о том, от чего вообще зависит скорость загрузки страниц и производительность сайта. Существует, на наш взгляд, ошибочное мнение, что все проблемы скорости загрузки сайта можно решить оптимизацией настроек или сменой хостинга. Это действительно помогает в случае нескольких классических ошибок настройки, которые мы рассмотрим ниже, однако, основные проблемы чаще всего кроются в неоптимальных алгоритмах, настройках «1С-Битрикс», проблемах с кэшированием.

Объясняется это довольно просто: современные процессорные технологии достигли пика частоты одного ядра. Что это означает для нас? В условиях, когда один запрос выполняется на одном ядре процессора — нет практически никаких возможностей ускорить время выполнения запроса в два раза. Скорее всего, у процессора на вашем сервере уже высокая частота и со сменой сервера она не станет в два раза выше. Серверы на хостинговых площадках чаще отличаются количеством оперативной памяти и количеством ядер/процессоров, на них расположенных.

Ситуацию можно сравнить со стойкой касс в супермаркете — одна касса может обслужить одного человека за определенное количество времени. Существует предел человеческих возможностей, быстрее которого в заданных условиях покупателя обслужить нельзя. Если в процессе покупки кассиру приходится забивать номер каждого товара в кассу руками, смена кассира может быть и поможет, но в два раза быстрее покупки оформляться не станут. Нужно менять саму процедуру покупки (а в нашем случае — оптимизировать код). Увеличение числа процессоров/ядер на сервере соответственно сравнимо с увеличением количества касс на стойке — одновременно можно обслужить больше покупателей, но каждый покупатель в отдельности будет недоволен.

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

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

Рассмотрим эти пункты в подробностях.

Аудит серверной конфигурации

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

1. Расположен ли сайт на виртуальном хостинге, VPS/VDS, виртуальной машине?

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

2. Какие версии ПО установлены на сервере?

PHP младше версии 5.5 и MySQL версии младше 5.5 мы рекомендуем к апгрейду. Важно: в случае если проблемы проекта прежде всего связаны с кодом — апгрейд PHP не приведет к ускорению сайта. Но если код оптимален и поддерживает такой переход — использование PHP версии 5.5 и выше может привести к ускорению времени генерации страницы на 20-30%, а использование PHP7 (в случае если проект PHP7-совместим) — к двукратному росту производительности на уровне PHP. Стоит помнить, если ваша страница генерируется за 1000мс, из которых 800мс занимают неоптимальные запросы к БД — даже двукратное ускорение PHP7 приведет к ускорению лишь на 100мс (время ответа станет 900мс вместо 1000мс). Время работы с базой данных от смены версии PHP не изменится.

3. Стоит ли оптимизатор PHP-кода?

В настоящий момент стандартом индустрии и рекомендуемым оптимизатором PHP является opcache. Кроме совершенно уникальных случаев использование opcache является обязательным. Прекомпиляция PHP-кода, которую осуществляет PHP-оптимизатор, ускоряет время обработки PHP-скрипта на 80-90%. Оптимизатор PHP занимается трансляцией PHP-кода в байт-код, который гораздо ближе к машинному. При использовании оптимизатора эта трансляция становится разовой процедурой, а при его отсутствии PHP выполняет трансляцию при каждом пользовательском запросе.

4. Отключен ли отладчик XDebug?

Отладчик XDebug является популярным модулем среди разработчиков, предназначенным для отладки кода. Его удобно и полезно использовать на серверах разработки, но на боевой машине XDebug замедляет время выполнения кода в два раза. Такую ситуацию мы видим довольно часто: XDebug остается запущенным после запуска нового сайта в бой, или же он остается установленным после срочной отладки на боевом сервере. XDebug обязательно надо выключать.

5. Проверка engine таблиц в MySQL

Несмотря на то, что в 2016 году MyISAM считается устаревшим «движком» таблиц, мы встречаем его использование на боевых сайтах. Возможно, причина в переносе таблиц с использованной при разработке базы данных, где тип движка не сильно критичен. Возможно на это просто не обратили внимание, а возможно этот тип таблиц использовали из исторически сложившихся предубеждений. В любом случае для типовых задач следует использовать InnoDB и его производные. MyISAM по своей структуре мало чем отличается от известного всем старого формата dbf-файлов, не предназначенного для промышленного использования в многопользовательской среде. MyISAM часто подвержен блокировкам на уровне таблицы (когда один запрос сайта заблокирует все остальные запросы), очень чувствителен к падениям MySQL (аварийное падение может привести к критической потере данных), с трудом поддается резервному копированию на лету (резервное копирование большой таблицы приведет к блокировке сайта). Всех этих проблем в InnoDB нет, однако, он должен быть корректно настроен.

6. Корректность настройки InnoDB

Прежде всего речь идет о размере buffer pool — внутреннем кэше MySQL. В случае если оперативной памяти достаточно, а размер данных невелик, мы рекомендуем выставить buffer pool выше, чем размер директории с данными (таким образом кэшировав все данные). При аудите хорошо помогают инструменты Percona Tools — в нашем блоге есть обзорная статья. Тема тюнинга MySQL довольно объемная, подробнее о ней поговорим в одной из ближайших статей.

7. Мониторинг работы сервера, проверка использования swap-а

Ни одна оптимизация не поможет, если сервер лежит под огромной нагрузкой из-за наплыва посетителей, или процессам не хватает памяти и часть их выгружена в swap. Swap-файл работает с жесткого диска, который в любом случае в сотни раз медленнее оперативной памяти. Мало того, обычно процессы настолько активно используют оперативную память, что в случае выгрузки ее на диск — дисковая подсистема сервера немедленно достигает своего предела и сайт перестает отвечать. На сервере должен стоять мониторинг: в момент «тормозов» важно понимать, что стало их причиной — сильное использование дисковой подсистемы, нехватка серверного CPU, а может быть вообще исчерпание пропускной способности сетевого интерфейса?

Аудит кода проекта

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

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

Для первоначального анализа долгих мест сайта мы используем монитор производительности 1С-Битрикс. Находим самые посещаемые из долго отвечающих страниц — их ускорение приведет к ощутимому снижению нагрузки на сервер. Если не учитывать популярность страницы, а обращать внимание только на скорость ответа, то можно потратить время на оптимизацию страницы, которую запрашивают раз в месяц и которая не создает реальной нагрузки.

Монитор производительности включается следующим образом: в административной панели сайта выбираем в меню «Настройки» -> Панель производительности -> Кнопка «Тестировать производительность». По окончании сбора данных во вкладке «Разработка» будет таблица со всеми посещенными страницами и временем их генерации.

После того как мы выбрали долгие страницы на отдельном сервере (мы знаем мощности этого сервера, и мы знаем, что сервер не загружен) анализируем время создания этих страниц в режиме отладки, смотрим на время генерации отдельных компонентов и понимаем, на что именно следует обратить внимание в анализе кода этих страниц. В первых итерациях мы проверяем как работают страницы в режиме с использованием кэширования, а в последних — изучаем работу сайта без кэша. Нередко страницы, которые открываются довольно быстро с использованием кэша, без него начинают открываться за 30-60 секунд. Казалось бы, ситуация когда кэш истек на редко посещаемых страницах не страшна, однако, пришедший в каталог поисковый бот может серьезно нагрузить сервер, начав обходить такие страницы.

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

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

Рассмотрим использование режима отладки и утилиты XHProf на примере страницы каталога с разделами. Проблема: при включенном кэшировании компонент Bitrix:catalog.section медленно исполняется.

Шаг 1. Обращаем внимание, что компонент не кэшируется и выполняется крайне медленно. При этом выполнение запросов занимает приблизительно 16% от времени исполнения компонента. Очевидно, что присутствуют какие-то проблемы в реализации компонента.

Шаг 2. Для отладки PHP используем XHProf. Оборачиваем нужный нам компонент в код утилиты XHProf.

Шаг 3. Обновляем страницу, чтобы XHProf собрал нужные нам данные.

Шаг 4. Открываем страничку с данными XHProf.

Шаг 5. Находим подключение нужного нам компонента Bitrix:catalog.section. Исполнение шаблона компонента Bitrix:catalog.section занимает 1,5 секунды, это большая часть времени генерации всей страницы.

Шаг 6. Идем дальше по стеку вызовов и находим вызов скрипта result_modifier.php. Если пройти дальше, то можно увидеть пользовательскую функцию, в которой исполняются запросы.

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

Давайте теперь пройдемся по самым частым проблемам, которые мы встречаем в результате аудита конфигурации 1С-Битрикса.

Аудит конфигурации «1С-Битрикс»

Неправильная структурная организация инфоблоков

Пожалуй, это наиболее распространенная проблема — встречается в 90% проектах. Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много.

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

«Самописные компоненты»

Часто встречаются ситуации, когда программисты и веб-студии используют сторонние, «авторские» компоненты, которые при этом не используют имеющиеся возможности платформы 1С-Битрикс. Например, самописные «умные фильтры» не используют фасетные индексы — это значительно увеличивает время исполнения компонента. Случается, что программисты не изучают детально устанавливаемый компонент и упускают из вида ошибки и проблемы, которые он добавляет. Рекомендуем тщательно анализировать устанавливаемые компоненты.

Проблемы с внешними сервисами

Это не связано с самим кодом 1С-Битрикс, но встречается у многих клиентов. Так или иначе многие сайты используют внешние сервисы для дополнительной функциональности на сайте: обновление курса валюты, расчет времени и стоимости доставки товара, API партнеров и т.п. Когда такой внешний сервис начинает долго отвечать — начинает долго отвечать и сам сайт. К сожалению, многие внешние сервисы всегда отвечают долго. Возможное решение проблемы — периодическая загрузка данных по заданию через Cron, и лучше если это будет происходить в наименее загруженное время работы проекта.

Проблемы с фасетными индексами

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

Ошибки использования API 1С-Битрикс

Выборка свойств в цикле после GetList, когда их можно выбрать в GetList. Сортировка и фильтрация средствами PHP вместо использования arFilter и arSort. В API 1С-Битрикс существует большое число функций, оптимальных для нагрузки на сервер. Разработчику необходимо знать эти функции и уметь их применять. Регулярной ошибкой является, например, получение списка товаров и последующее получение их свойств в цикле, в то время, когда свойства можно получить в основном запросе. Таким образом, например, получив 100 товаров, мы создаем дополнительно 100 запросов к базе данных для получения свойств. Не стоит также выбирать товары для их подсчета — в API 1С-Битрикс есть для этого специальная функциональность. Удивительно, но очень часто мы видим как товары выбираются для того, чтобы посчитать часть из них по какому-то свойству.

Проблемы при генерации меню

В больших проектах становится проблемой генерация меню (либо секций каталога) с подсчетом количества элементов в категориях/секциях. Исходя из этого количества элементов как раз и строятся вышеуказанные области. Для оптимизации скорости работы проекта мы не рекомендуем использовать данную функцию. Подробный кейс был подробно рассмотрен в сообществе разработчиков Битрикс.

Ещё довольно часто наблюдаем проблемы с доработанными меню. К примеру, разработчики не обратили внимание, что меню не кэширует вывод шаблона и написали меню с включением в него самого популярного товара по каждой категории. Получилось, что при просмотре пользователем меню на каждый элемент создаются запросы к базе (что, естественно, замедляет работу проекта). Сам 1С-Битрикс реализует данную «кастомную» функциональность через включение компонентов с такими элементами в result_modifier.php.

Включенный антивирус

Веб-антивирус занимается проверкой страниц сайта на вредоносный контент, который мог быть добавлен в результате взлома/модификации страниц. Хотя эта функциональность и полезна, мы, обычно, рекомендуем отключать этот модуль, оставив включенным модуль проактивной защиты — отключение веб-антивируса может ускорить загрузку страницы на 100-200 мс.

Установленный модуль компрессии

Модуль компрессии предназначен для хостинговых площадок, в которых включить компрессию на уровне веб-сервера не представляется возможным — в основном на «древних» shared-хостингах. В случае, если gzip-компрессию на уровне веб-сервера вы включить можете (а в большинстве случаев это возможно) — мы рекомендуем отключить этот модуль.

Агенты выполняются на хитах

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

Некорректное использование кэширования

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

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

Проблемы с композитным кэшем

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

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

Сам кэш может отдаваться не только из файлов и memcache, но и в виде статических файлов на уровне nginx, однако это используется очень редко. Подробнее про настройку nginx для работы с композитом прочитать на сайте курса разработчиков Bitrix.

Проверка клиентской части

Изображения без оптимизации

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

Проблемы с JS/CSS файлами

Тут регулярно встречаются две проблемы: это подключение JS/CSS файлов нестандартным для Битрикса способом и использование необъединённых JS/CSS файлов. Пост в сообществе разработчиков на эту тему.

Самое важное — неправильное подключение отменяет возможность автоматического объединения JS/CSS файлов, и также отменяет автоматическое обеспечение правильного порядка их подгрузки (сначала CSS файлы, потом JS-файлы).

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

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

Отдача статики веб-сервером Apache

Как ни удивительно, но до сих пор мы довольно часто встречаем ситуации, когда легковесные статические файлы отдаются не через фронтенд в виде nginx или ему подобный легкий веб-сервер, а через Apache, с которого часто (в особенности при использовании Bitrix Env) раздается динамика. При этом каждый такой запрос создает дополнительное потребление оперативной памяти (Apache значительно тяжелее) и нагрузку на процессор. Мы настоятельно рекомендуем убедиться, что отдачей статики занимается nginx.

Отсутствие компрессии на уровне веб-сервера

Тут все просто — статику надо отдавать с gzip-компрессией, это периодически упускается, к сожалению. Убедиться, что статика отдается с компрессией можно, например, тут.

Подводим итоги

Значимость скорости загрузки сайтов растет: поисковики готовят штрафы в позициях выдачи для медленных сайтов, пользователи наказывают «рублем» и уходят к более шустрым конкурентам. Мы хотим, чтобы хороших и быстрых сайтов было как можно больше. Используйте ресурсы хостинга и платформы 1С-Битрикс грамотно, чтобы получить качественный во всех отношениях проект, который не стыдно разместить в портфолио. Надеемся, наши рекомендации помогут вам в решении проблем производительности проекта. И не забудьте поделиться статьей в соцсетях, если для вас она оказалась полезной.

Оставляя настройки кэширования по умолчанию, есть риск по мере увеличения числа страниц столкнуться со значительным ростом кэша меню. Наиболее это заметно на сайтах, где выпадающее меню отображает большое количество разделов и подразделов. Дело в том, что согласно исходным настройкам «Битрикс» создает для каждой страницы индивидуальный кэш меню. Например, на сайте 15000 карточек товаров, и для каждого автоматически создается кэш верхнего меню на 100 килобайт. В итоге получается 1500 мегабайт. Полтора гигабайта! Как же избежать бесполезной траты системных ресурсов и времени на загрузку?

1. Где в «Битрикс» определяется кэш меню?

Это делается в файле class.php по адресу /bitrix/components/bitrix/menu/class.php следующим кодом:

public function getCacheID($additionalCacheID = false)
   {
      /** @global CMain $APPLICATION */
      global $APPLICATION;
      /** @global CUser $USER */
      global $USER;

      $strCacheID = "";
      if($this->arParams["MENU_CACHE_TIME"])
      {
         if($this->arParams["CACHE_SELECTED_ITEMS"])
            $strCacheID = $APPLICATION->GetCurPage();
         else
            $strCacheID = "";
         $strCacheID .=
            ":".$this->arParams["USE_EXT"].
            ":".$this->arParams["MAX_LEVEL"].
            ":".$this->arParams["ROOT_MENU_TYPE"].
            ":".$this->arParams["CHILD_MENU_TYPE"].
            ":".LANGUAGE_ID.
            ":".SITE_ID.
            ""
         ;

         if($this->arParams["MENU_CACHE_USE_GROUPS"] === "Y")
            $strCacheID .= ":".$USER->GetGroups();

         if($this->arParams["MENU_CACHE_USE_USERS"] === "Y")
            $strCacheID .= ":".$USER->GetID();

         if(is_array($this->arParams["MENU_CACHE_GET_VARS"]))
         {
            foreach($this->arParams["MENU_CACHE_GET_VARS"] as $name)
            {
               $name = trim($name);
               if($name != "" && array_key_exists($name, $_GET))
                  $strCacheID .= ":".$name."=".$_GET[$name];
            }
         }

         $strCacheID = md5($strCacheID);
      }

      return $strCacheID;
   }

Конкретно кэш меню определяется в строках:

if($this->arParams["CACHE_SELECTED_ITEMS"])
   $strCacheID = $APPLICATION->GetCurPage();
else
   $strCacheID = "";

Пока параметр параметр CACHE_SELECTED_ITEMS включен, для каждой страницы создается свой кэш меню.

2. Теперь как его отключить?

Применим в файле class.php по адресу /bitrix/components/bitrix/menu/class.php следующий код:

<?$APPLICATION->IncludeComponent("bitrix:menu", "top", Array(
   "ROOT_MENU_TYPE" => "top",   // Тип меню для первого уровня
   "MENU_CACHE_TYPE" => "A",   // Тип кеширования
   "MENU_CACHE_TIME" => "3600",   // Время кеширования (сек.)
   "MENU_CACHE_USE_GROUPS" => "N",   // Учитывать права доступа
   ...
   "CACHE_SELECTED_ITEMS" => "N", // Не создавать кеш меню для каждой страницы
   ),
   false
);?>

Готово!

Назад в раздел

В вашем случае проблема может заключаться в том, что система кеширует данные без учета прав доступа групп.
Для компонента(будь то меню, раздел, каталог) в CMS Bitrix, при его вызове, можно задать настройки кеширования, передав в массиве настроек компонента(передаваемого при вызове метода $APPLICATION->IncludeComponent) параметр:

CACHE_TYPE — Тип кэширования.
Варианты:

1. A — Авто: автоматически обновляет кэш компонентов в течение заданного времени;
2. Y — Кэшировать: для кэширования необходимо определить время кэширования;
3. N — Не кэшировать: кэширования нет в любом случае.

CACHE_TIME — Время кеширования
В первом варианте, также задается значение переменно CACHE_TIME, в секундах.

CACHE_GROUPS — Учитывать права групп при кешировании
Также при настройки кеширования можно указать значение данного параметра, в Y или N, который сообщит системе, кешировать с учетом прав доступа групп или нет.

Очистка кеша из PHP

$staticHtmlCache = BitrixMainDataStaticHtmlCache::getInstance();
$staticHtmlCache->deleteAll();

Отмена композита в любом месте страницы

BitrixMainDataStaticHtmlCache::getInstance()->markNonCacheable();