Когда-то (в ноябре 2010) я писал про особенность таблицы b_sale_fuser и ее разбухание на активных проектах http://dev.1c-bitrix.ru/community/web...blog/2323/ Скоро уже 4 года с момента выхода поста. А что же нового?
В этот раз я проанонсирую один из вариантов диагностики и чистки, а также вкратце покажу пример устранения одной из первопричин такого поведения. Ведь устранение причины - гораздо лучше борьбы с последствиями [spoiler] Итак. Инструменты диагностики и чистки Я снова встретил на нескольких своих проектах признаки разбухания b_sale_fuser На модерации находится модуль инспектор Я решил внести в него также функционал по диагностике и тестированию эффекта, когда чистка корзин не справляется с реальной скоростью их формирования Детали смотреть в посте http://dev.1c-bitrix.ru/community/web...blog/2323/
Что теперь можно будет сделать с помощью модуля. 1. в один клик определить все ли ок на проекте с таблицей b_sale_fuser
2. Произвести чистку, если это необходимо
P.S. Ссылку на модуль я прикреплю позже, как только он пройдет модерацию
И обещанный пример того, как можно устранить саму причину Внимание, источников разбухания может быть много и они уникальны на проектах, но есть и классика. Понять причину очень легко, если вы ознакомитесь с комментариями в документации к методу CSaleBasket::GetBasketUserID Именно он и есть - основной источник роста количества корзин, а следовательно и записей таблицы b_sale_fuser Однако, разработчики заложили в него небольшую хитрость, см комментарии в документации, которую мы и используем для борьбы с эффектом разбухания.
Итак самым плодовитыми в плане создания корзин (записей таблицы b_sale_fuser) по статистике является.... компонент малая корзина bitrix.basket.basket.small. Та самая вездесущая малая корзина Именно этот компонент под атаками ботов и прочей нежити (кстати, прутая посещаемость тоже может способствовать) и может не выдержать оборону.
говорят по сути о том, что надо или нет, но всегда для пользователя будет существовать уже готовая корзина. Даже если она на проекте не понадобится, ее нам создадут. Ну а боты... получат далеко не одну корзинку на душу населения.
Что мы сделаем используем спецпараметр, который запретит создание корзины, если ее не найдено и слегка модернизируем код, чтобы обеспечить его стабильность при использовании спецпараметра.
Мне кажется или в 14.5 анонсировали какой-то функционал модуля ИМ, касающийся брошенных корзин? Вроде как время их хранения задать можно. И что, функционал анонсировали, а таблицы по прежнему растут? Ужас-ужас...
Больше только бесит распухание таблицы управляемого кеша.
Да, Антон Долганин прав на все 100. Тут спорная проблема. Она действительно глубокая и давняя. Нельзя сказать, что архитектура Битрикс не верна. Но вот малую корзину я бы переписал. Реально много сайтов из-за нее страдает. Хотя не только из-за нее. Возможно, если будет время опишу еще несколько "убийц"
--------------------- Важный комментарий Коллеги, особенно это касается новичков. Будьте внимательны. Когда я писал "заменяем строки", я имел в виду кастомизацию компонента и превращение его в свой компонент --------------------
Тут мне еще подсказали в модуль встроить детектор, который будет автоматически сигнализировать о симптомах переполнения. И отправляет администратору сообщение по почте, чтобы он проверил, все ли в порядке. Ставлю в план разработки
касающийся брошенных корзин
Алексей Задойный , Битрикс анализирует брошенные строки корзин А есть еще сама сущность - корзина. Она хоть и пустая, но в реальности на всех 100% битрикс магазинов каждому юзверьку уже полагается своя собственная металлтическая тележечка. Это и есть запись b_sale_fuser
Кстати еще парадокс восприятия Есть настройка "Хранить корзину N дней". Это и есть лимит, когда невостребованная тележка отправляется в утиль. Переполнение - это как раз, когда в утиль не успевает система отправлять тележки и они копятся в рабочих таблицах. Захламляют бекапы и т.д.
Но ее некоторые понимают как удаление "просроченных товаров" А вот как бы и не так. Это именно дата обновления той самой тележечки. Т.е. если я зашел в магазин, магазин меня узнал и увидел мою персональную тележку, он мне ее подкатит, а не станет создавать новую. В том числе и со всеми брошенными в ней товарами. А значит если я брошу в корзину какой то товар и буду систематически посещать магазин, этот товар будет болтаться в корзине вечно.
Коллеги, так я это прекрасно понимаю! Просто на мой взгляд было бы логично решить проблему накопления пустых ненужных тележек раньше, чем нанимать таджиков, которые будут ходить по складу тележек, находить непустые (но просроченные) и просто вынимать из них продукты. Понятно, что проще, то и сделали... От того и грустно. От того и упомянул про таблицу управляемого кеша - там всё примерно так же грустно. На одном проекте какие-то дикие миллионы записей там были, так что даже ощутимая нагрузка возникала при обращениях.
Еще стоит обратить внимание на второй параметр агента CSaleUser: DeleteOldAgent(10, 600). По умолчанию второй параметр 0, а это означает запуск данного агента через 3 часа, его нужно задавать также как и интервал в секундах. P.S.: При изменении настроек в модуле Интернет-магазин параметр сбрасывает.
Юрий Классман спасибо за комментарий, про агентов уже писали еще в старом посте от 2010 года. (кстати в модуле инспектор просто происходит вызов функции агента до полного изничтожения излишков)
Но в данном случае пост посвящен не столько средствам диагностики или борьбе с последстваиями, сколько концентрации на том, что причины то тоже искать надо.
Ну а нежданчик, что малая корзина является одной из таких причин, для многих пока еще нежданчик.
Про малую корзину согласен! На проектах с большим количеством посетителей всегда делаю как описано выше. Я больше хотел написать про второй параметр в агенте, о его назначении.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».