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

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

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

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.itgrix.ru/for-admins/work_acceleration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.