Пользователь 1444

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

• HTTP_USER_AGENT - для отличия мобильных и десктопных браузеров
  
• HTTP_ACCEPT - проверять поддержку WEBP
  
• COOKIE - в зависимости от кук
  

https://dev.1c-bitrix.ru/community/web...#com116715

Я реализовал небольшой хак через rewrite в Nginx. Мой метод основан на добавлении в $_SERVER["REQUEST_URI"] дополнительных переменных через Nginx. Далее привожу 2 примера.

Первый пример для HTTP_USER_AGENT:

В секции для нужного хоста в Nginx добавляю:

if ($http_user_agent ~* "mobile")
{
    rewrite ^/composite_test/$ /composite_test/?MOBILE=Y break;
}

В случае с мобильным браузером в Apache уходит url с дополнительным параметром MOBILE=Y и в $_SERVER["REQUEST_URI"] будет /composite_test/?MOBILE=Y, при этом url в браузере останется /composite_test/.

Важно делать это через Nginx, а не Apache. Битрикс использует $_SERVER["REQUEST_URI"] для построения ключа композитного кеша и не использует $_SERVER["QUERY_STRING"].

Если использовать mod_rewrite в Apache, то MOBILE=Y попадёт в $_SERVER["QUERY_STRING"], а $_SERVER["REQUEST_URI"] останется таким же.

Второй пример для COOKIE:

Nginx поддерживает cookie и можно написать условие вида:

if ($cookie_VARNAME = 1)
{
        rewrite ^/composite_test/$ /composite_test/?VARNAME=1 break;
}

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

В целом можно использовать любые переменные доступные в Nginx и таким образом формировать разные url для Apache.

Я привел базовые примеры, которые можно адаптировать под нужды конкретного проекта. Правда замечу, что необходимо иметь доступ к настройкам Nginx на сервере.

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

Столкнулся с проблемой очень долго удаления элементов инфоблока (2-4 секунды).

• Товары, нём примерно 150.000 позиций (IBLOCK_ID = 3)
  
• Фотографии, в нём примерно 80.000 позиций и каждая имеет множественную привязку к товарам (IBLOCK_ID = 7)
  

Речь идёт про витрину товаров на редакции Стандарт.

Товары часто добавляются и удаляются, и удаление одного товара занимало 2-4 секунды, для удаления 100 товаров уже требовалось несколько минут.

Посмотрел slow_query log в mysql, обнаружил что очень долго выполняется запрос такого плана:

DELETE FROM b_iblock_element_prop_m7 WH ERE IBLOCK_PROPERTY_ID IN (17) AND VALUE_NUM=1559484;

Проблема была в удалении привязанных фоток. При удалении из инфоблока с товарами #3, проверяются все связи и в частности в инфоблоке с фотками #7.

Посмотрел таблицу свойств для инфоблока с фотками #7 b_iblock_element_prop_m7 и увидел, что нет индекса по полям IBLOCK_PROPERTY_ID+VALUE_NUM.

Добавление индекса дало прирост с 2-4 секунд до 0.00008. Фактически удаление стало мгновенным.

В таблицах свойств для товаров содержится 705 000 записей = 170 мб

В таблице свойств для содержится 780 000 записей = 510 мб

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

• железо: VDS на SSD у FirstVDS, 6 Гб память и 6 ядер процессор
  
• софт: bitrix_env, mysql percona 5.7.21, php 7.2.31, битрикс 20.0.650