Бизнес-процессы Битрикс24: гибкость, удобство… тормоза. Проблема и решение

• Анализ проблемы
• Как работают с системой
• Что решено предпринять
  • Рефакторить и оптимизировать инфоблоки
  • Отказаться от инфоблоков в пользу чего-то быстрого
  • Оставить инфоблоки для бизнес-процессов, а чтение и фильтрацию доверить чему-то быстрому
• Описание решения. Что делали
• Наладка синхронизации
• Результаты

— Как сделать так, чтобы инфоблоки не тормозили?
— Не использовать инфоблоки.
Подслушано.

Бизнес-процессы Битрикс24 позволяют быстро и относительно просто автоматизировать повторяющиеся последовательности действий.

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

Это естественная расплата за гибкость и простоту.

Мы нашли способ устранить этот недостаток — перевести все отчеты на highload-блоки Битрикс, оставив в живых бизнес-процессы.

Поехали.

Что такое бизнес-процессы в Битрикс24 мы уже рассказывали в постах Бизнес-процессы в CRM и Где искать бизнес-процессы в Битрикс24 и как ими управлять. Бизнес-процессы можно запустить на любом элементе CRM или на элементе инфоблока. Но что делать, если данных в инфоблоках так много, что страницы с поиском и отчетами открываются по 10-15 секунд? Как ускорить ИБ, сохранив бизнес-процессы в проекте?

Вам может быть интересно:

Автоматизация бизнес-процессов в Битрикс24

Анализ проблемы

Как работают с системой

Наш заказчик — коллекторское агентство. Клиентов у компании много, по каждому собрана подробная информация (более 70 полей в карточке клиента) и ведутся десятки документов. Битрикс 24, как и положено для проекта такого калибра — коробочный.

Пополняется и обновляется база клиентов из нескольких источников:

• импорт из файлов;
• заполнение вручную;
• выгрузки из 1С.

Одна из важнейших функций — поиск карточек дел должников по фильтру (более 50 параметров). В день в среднем совершается 71865 поисков (это 3-4 поиска в секунду в рабочие часы). Когда клиент обратился к нам, страница результатов поиска загружалась за 15 секунд.

Запись данных в БД происходит намного реже — соотношение где-то 10 операций чтения к 1 операции записи.

Компания растёт и набирает новых клиентов, планируется много новых функций Битрикс24, что только увеличит нагрузку.

Что решено предпринять

После анализа проблемы выработали три возможных решения:

• рефакторить и оптимизировать инфоблоки;

• отказаться от инфоблоков в пользу чего-то быстрого;

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

Рефакторить и оптимизировать инфоблоки

Первым делом, возникла мысль заняться рефакторингом кода и оптимизацией ресурсов. Однако, вскрытие показало, что проект вполне здоров с точки зрения кода. Покупкой нового железа проблема тоже не решалась. Усердная оптимизация определенно дала бы ускорение на 10-15%, и то не надолго. Данных с каждым днем становится больше, продолжают появляться новые поля, поэтому замедление фильтрации и поиска по инфоблокам все равно не заставит себя долго ждать.

Отказаться от инфоблоков в пользу чего-то быстрого

В принципе, проблема “инфоблоки тормозят” давно ни у кого не вызывает бурных эмоций. В большинстве случаев проблему решают переходом на highload-блоки (ведь они для того и нужны) или свои таблицы. В новом ядре D7 есть быстрое API, их развивают и всё вроде бы хорошо...  но бизнес-процессы с хайлоад-блоками не работают.

Отказаться от бизнес-процессов нельзя. Для 9 из 10 дел должников постоянно запущен какой-либо БП. Они многошаговые, глубоко проникли в рабочий процесс компании и могут тянуться годами. Почти все задачи в портале для сотрудников заказчика выставляются автоматически через БП.

Оставить инфоблоки для бизнес-процессов, а чтение и фильтрацию доверить чему-то быстрому

Тогда появилась идея ввести “разделение труда”: пусть поиск работает по highload-блокам (раз они такие быстрые), а бизнес-процессы работают с инфоблоками. Данные должны храниться одновременно в инфоблоках и в highload-блоках и поддерживаться в актуальном состоянии.

Вам может быть интересно:

Как делать highload на Битриксе

Описание решения. Что делали

Чтобы перевести проект на highload, нужно было:

• воссоздать в highload-блоках структуру ИБ со всеми полями и связями;

• конвертировать данные;

• адаптировать интерфейс;

• наладить синхронизацию данных.

Создавать HL-копии инфоблоков можно было бы сделать вручную, но в нашем случае в каждом из 9 инфоблоков хранится в среднем по 30 тысяч элементов. Плюс записи в инфоблоках связаны друг с другом. Если предположить, что у человека пересоздание записи с 20 свойствами займёт 1 минуту, то на 30 тысяч уйдет 500 часов. И это только на один инфоблок.

Поэтому, для переноса структуры и данных был написан небольшой конвертер, который не только создавал highload-блок, добавлял в него все нужные поля, но и копировал записи. Сильно облегчило задачу то, что при добавлении записи в highload-блок можно указывать ее ID, что позволило перенести данные “1 в 1”, сохранив целостности связей без изменения привязок по ID.

Переписывать код интерфейса глобально не пришлось. Вся работа с данными была скрыта в паре классов, так что заменили только “начинку”, почти не меняя html.

Наладка синхронизации

Простой переход на highload-блоки ускорил чтение и фильтрацию в 5 раз. Тут и началось самое интересное. Нужно было синхронизировать все, что происходит в highload-блоках с инфоблоками и наоборот. Любое изменение как со стороны пользователя, так и со стороны 1С должно обновлять инфоблоки, чтобы Бизнес-процессы всегда работали с актуальной информацией, а каждое изменение данных бизнес-процессом должно быть сразу доступно для работы пользователю.

Решалась такая задача с помощью событий Битрикс24 и привязки каждого элемента highload-блоков к элементу-дублеру в инфоблоках.  При возникновении события удаления, добавления или обновления элемента в HL или ИБ, происходит поиск дублера и синхронизация всех новых данных. Делать это нужно внимательно и аккуратно, чтобы избежать зацикливания событий, срабатывающих всякий раз при изменении.

Результаты

После всего проделанного, мы получили прирост скорости выполнения фильтрации и чтения данных в 5 раз. Выборка, для которой страница грузилась до 15 секунд теперь отрабатывает за 2,5-3. Мы даже добавили по просьбе клиента новые, ещё более сложные фильтры, а скорость работы практически не изменилась. А вот операции записи пострадали: новое дело создается за 4 секунды против прежних 1-1.5, потому что запись происходит и в ИБ, и в HL, а также осуществляются дополнительные проверки на зацикливание, вызовы обработчиков и пр.

Графики “до-после для чтения и записи”

Но этому можно было помочь. После перехода на highload-блоки в инфоблоках дублировалась вся информация из highload-блоков, а нужна только та, которая задействована в бизнес-процессах. Оставалось только “облегчить” инфоблоки удалением “лишних” свойств (в некоторых ИБ таких была почти половина). Чистку проводили вручную, каждое поле пришлось анализировать и проверять, где и как используется, обсудить с заказчиком будущие бизнес-процессы, однако все это помогло ускорить работу с записью данных. Дело, которое создавалось 4 секунды, стало создаваться за 2-2.5 (Как все-таки свойства инфоблоков сильно замедляют работу...).

Графики “до-после для чтения и записи” после удаления свойств ИБ

Это лишь один из примеров сложных доработок Битрикс24, которые мы делаем. Любую задачу можно решить, если правильно к ней подойти и применить соответствующие компетенции.

Ваш Битрикс24 тормозит и мешает быстро выполнять задачи? — Обращайтесь к нам, решение обязательно найдется!