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

Новое в Itgrix_bx 3.4.0

Главный показатель производительности нашей интеграции – это количество звонков, которые модуль может обработать в единицу времени, не создавая задержек. Иногда приходят тысячи звонков в час, иногда колл-центр делает сотню одновременных исходящих звонков, и в этих ситуациях крайне важно не отставать в обработке, чтобы карточки звонков отображались и исчезали вовремя, и новые лиды регистрировались незамедлительно.

В версии 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 раз.

У колл-центров количество звонков измеряется тысячами в час. Тесты показывают, что теперь наша интеграция может справиться более чем с десятью тысячами звонков в день без задержек.

Модуль интеграции готов для клиентов с большой нагрузкой.