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

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

В версии [3.4.0](https://docs.itgrix.ru/changelog-bx#3.4.0) мы уделили этому вопросу много внимания и добились огромного успеха – улучшения производительности на порядок.

Чтобы понять, какие произошли изменения, посмотрим на работу предыдущих версий, вплоть до предпоследней [3.3.5](https://docs.itgrix.ru/changelog-bx#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 раз.**

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

{% hint style="success" %}
**Модуль интеграции готов для клиентов с большой нагрузкой.**
{% endhint %}