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

Главный показатель производительности нашей интеграции – это количество звонков, которые модуль может обработать в единицу времени, не создавая задержек. Иногда приходят тысячи звонков в час, иногда колл-центр делает сотню одновременных исходящих звонков, и в этих ситуациях крайне важно не отставать в обработке, чтобы карточки звонков отображались и исчезали вовремя, и новые лиды регистрировались незамедлительно.
В версии 3.4.0 мы уделили этому вопросу много внимания и добились огромного успеха – улучшения производительности на порядок.
Чтобы понять, какие произошли изменения, посмотрим на работу предыдущих версий, вплоть до предпоследней 3.3.5.
Как работала последовательная обработка
В основе работы модуля интеграции Itgrix лежит обработка событий звонков из Asterisk. Набрали номер, зазвонил телефон, взяли трубку – эти и другие события моментально появляются в CEL, модуль их видит и реагирует.
Процесс чтения событий звонков, их интерпретации и реакции на них выполнялся последовательно, одно событие за другим.
В результате, если два события происходили одновременно (например зазвонили телефоны у двух сотрудников), реакция на них происходила последовательно.
Огромным замедляющим фактором здесь было строгое ограничение Битрикса: максимум два запроса в секунду. Это значит, что если для какого-то действия нам нужно отправить два запроса, то на его выполнение уходило минимум по секунде. Звонит 10 телефонов – у последнего карточка задержится на 10 секунд.
Группировка запросов
Битрикс предоставляет удобный инструмент для обхода ограничения на запросы: их можно группировать в пакеты и отправлять до 50 штук за раз, как один.
Чтобы складывать запросы в такие пакеты, их нужно писать немножко по-другому. Основная хитрость в том, как организовать добавление запроса в пакет, своевременную отправку пакета и получение результата. Это и был первый большой шаг к улучшению производительности.
Параллельная обработка событий
С возможностью отправлять много запросов одновременно, стало возможным и обрабатывать несколько событий одновременно. Однако, некоторые из них логически связаны друг с другом. Поэтому интерпретация и реакция на события каждого отдельного звонка были выстроены в отдельные очереди событий.
Реакция на события внутри очереди выполняется последовательно, но события из разных звонков независимы и обрабатываются параллельно.
Результаты
Благодаря этим изменениям, стало возможно работать с множеством событий одновременно и не ждать завершения обработки тех событий, результат которых не требуется для совершения дальнейших действий. Теперь мы можем отправлять не два запроса в секунду, а уже сто запросов. Конечно же, мы хотели протестировать и измерить как изменилась производительность.
Для оценки мы выбрали такую меру: берём большое количество событий, ставим их все в очередь на обработку и замеряем время до завершения процесса. Выборку событий сделали по случайным звонкам.
Вот что получилось:
Тест
Itgrix_bx 3.3.4
Itgrix_bx 3.4.0
10 звонков
18.7 с
5.4 с
100 звонков
5 м 23 с
48 с
1000 звонков
41 м 53 с
5 м 39 с
Поскольку в тестах используются случайные звонки, результаты немного плавают. Но самое разительное улучшение очевидно: за примерно пять с половиной минут, прошлая версия справлялась с сотней звонков, а новая – уже с тысячей. Рост производительности в 10 раз.
У колл-центров количество звонков измеряется тысячами в час. Тесты показывают, что теперь наша интеграция может справиться более чем с десятью тысячами звонков в час без задержек.
Модуль интеграции готов для клиентов с большой нагрузкой.

Обработка звонков за период

Настройка прав на просмотр детализации звонков

Last modified 8mo ago

Copy link

Outline

Как работала последовательная обработка

Группировка запросов

Параллельная обработка событий

Результаты