Comment on page
Ускорение работы модуля за счет параллельной обработки звонков
Новое в 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 раз.
У колл-центров количество звонков измеряется тысячами в час. Тесты показывают, что теперь наша интеграция может справиться более чем с десятью тысячами звонков в час без задержек.
Модуль интеграции готов для клиентов с большой нагрузкой.