Бизнес-процессы Битрикс24 позволяют быстро и относительно просто автоматизировать повторяющиеся последовательности действий.
Можно легко вносить изменения и поддерживать сотни процессов. Однако при большом объеме данных (тысячи записей, сотни полей данных, десятки запущенных заданий) бизнес-процессы работают все медленнее. Еще медленнее работают отчеты по лидам, задачам и собственным надстройкам.
Это естественная расплата за гибкость и простоту.
Мы нашли способ устранить этот недостаток — перевести все отчеты на highload-блоки Битрикс, оставив в живых бизнес-процессы.
Поехали.
Что такое бизнес-процессы в Битрикс24 мы уже рассказывали в постах Бизнес-процессы в CRM и Где искать бизнес-процессы в Битрикс24 и как ими управлять . Бизнес-процессы можно запустить на любом элементе CRM или на элементе инфоблока. Но что делать, если данных в инфоблоках так много, что страницы с поиском и отчетами открываются по 10-15 секунд? Как ускорить ИБ, сохранив бизнес-процессы в проекте?
Анализ проблемы
Как работают с системой
Наш заказчик — коллекторское агентство. Клиентов у компании много, по каждому собрана подробная информация (более 70 полей в карточке клиента) и ведутся десятки документов. Битрикс 24, как и положено для проекта такого калибра — коробочный.
Пополняется и обновляется база клиентов из нескольких источников:
- импорт из файлов;
- заполнение вручную;
- выгрузки из 1С.
Одна из важнейших функций — поиск карточек дел должников по фильтру (более 50 параметров). В день в среднем совершается 71865 поисков (это 3-4 поиска в секунду в рабочие часы). Когда клиент обратился к нам, страница результатов поиска загружалась за 15 секунд.
Запись данных в БД происходит намного реже — соотношение где-то 10 операций чтения к 1 операции записи.
Что решено предпринять
После анализа проблемы выработали три возможных решения:
- рефакторить и оптимизировать инфоблоки;
- отказаться от инфоблоков в пользу чего-то быстрого;
- оставить инфоблоки для бизнес-процессов, а чтение и фильтрацию доверить чему-то быстрому.
Рефакторить и оптимизировать инфоблоки
Первым делом, возникла мысль заняться рефакторингом кода и оптимизацией ресурсов. Однако, вскрытие показало, что проект вполне здоров с точки зрения кода. Покупкой нового железа проблема тоже не решалась. Усердная оптимизация определенно дала бы ускорение на 10-15%, и то не надолго. Данных с каждым днем становится больше, продолжают появляться новые поля, поэтому замедление фильтрации и поиска по инфоблокам все равно не заставит себя долго ждать.
Отказаться от инфоблоков в пользу чего-то быстрого
В принципе, проблема “инфоблоки тормозят” давно ни у кого не вызывает бурных эмоций. В большинстве случаев проблему решают переходом на highload-блоки (ведь они для того и нужны) или свои таблицы. В новом ядре D7 есть быстрое API, их развивают и всё вроде бы хорошо... но бизнес-процессы с хайлоад-блоками не работают.
Отказаться от бизнес-процессов нельзя. Для 9 из 10 дел должников постоянно запущен какой-либо БП. Они многошаговые, глубоко проникли в рабочий процесс компании и могут тянуться годами. Почти все задачи в портале для сотрудников заказчика выставляются автоматически через БП.
Оставить инфоблоки для бизнес-процессов, а чтение и фильтрацию доверить чему-то быстрому
Тогда появилась идея ввести “разделение труда”: пусть поиск работает по 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 тормозит и мешает быстро выполнять задачи? — Обращайтесь к нам, решение обязательно найдется.
Полезные ссылки:
• Разработка и доработка проектов на 1С-Битрикс.
• Настройка интеграции с 1С любой сложности.
