Нагрузочное тестирование IP-АТС Asterisk, установленной на сервере средней мощности

Прямые измерения нагрузочной способности IP-АТС Asterisk на процессоре Intel Xeon E5506 Quad-Core показали, что эта система может обслуживать до 1600 параллельных звонков.

Вместо предисловия

Описанный ниже тест был выполнен в июле 2014 г. C тех пор он не потерял актуальности и позволяет судить о масштабируемости инсталляций IP АТС Asterisk.

Важной отличительной особенностью этого теста является примененный в нем метод генерации нагрузки с помощью системы автоматического обзвона Loway WombatDialer. Такая схема позволяет легко провести нагрузочное тестирование любой конкретной конфигурации, включающей IP АТС.

Важный момент: на тестируемом сервере не использовалась какая-либо платформа виртуализации, и не было установлено никакое вспомогательное ПО, которое в реальных условиях часто дополняет инсталляцию Asterisk/FreePBX.

***

IP-АТС Asterisk- выдающийся образец свободно распространяемого ПО, который, многократно доказав свою надежность и эффективность, широко применяется во всем мире, повторив успех Linux.

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

Распространено мнение, что Asterisk можно успешно использовать только в небольших системах — примерно до 300 абонентов, и именно этот фактор во многом сдерживает более широкое распространение этой чрезвычайно эффективной системы.

При этом опубликованных результатов прямых измерений нагрузочной способности Asterisk мы не встречали — по-видимому, в связи с трудностями создания или моделирования реальной нагрузки.

Для автоматизации нагрузочного тестирования и моделирования реальной нагрузки нами была использована система Wombat Dialer, любезно предоставленная швейцарской компанией Loway.

Изначально интегрированный с IP-АТС Asterisk, Loway Wombat Dialer как нельзя лучше подходит для решения поставленной задачи. Его изначальным назначением является автоматизация обзвона клиентов.

Ранее, выполнив прямое нагрузочное тестирование IP АТС Asterisk, установленной на маломощной виртуальной машине облачного сервиса Hetzner, мы уже выяснили, что даже такая инсталляция вполне может обеспечить рабочую нагрузку в 70 параллельных разговоров (с необходимым запасом).

В новом тесте схема моделирования нагрузки не отличается от примененной для случая облачной инсталляции Asterisk. Важное отличие состоит в том, что источник нагрузки и тестируемый сервер установлены в 100 Mb — локальной сети, поскольку интернет-соединения с требуемой полосой (до 100 Mb) не было в нашем распоряжении.

Рис. 1. Схема эмуляции нагрузки

Сервер, генерирующий тестовые звонки (#1), размещен на виртуальной машине VMware. Сервер, принимающий звонки (#2, тестовый сервер)- физический сервер: процессор Intel Xeon E5506 Quad-Core, память — 16GB, диск — 250 GB. Используемая ОС — Ubuntu (3.2.0–63-generic #95-Ubuntu). Версия Asterisk — 11.8.1 (в составе FreePBX 2.11.0.35).

Loway Wombat Dialer подключен к серверу Asterisk, генерирующему тестовые звонки. Между серверами Asterisk был создан SIP транк.

Моделирование реальной нагрузки включало обработку медиа- потока, передаваемого по протоколу RTP.

Нагрузка создавалась следующим образом: звонки шли из локального сервера на заданный номер тестируемого сервера, который устанавливал соединение и проигрывал музыку в течение 8 минут — достаточного интервала для проведения всего теста. При соединении с этим номером сервер Asterisk, генерирующий тестовые звонки, соединял его с собственным локальным номером, с которого непродолжительно проигрывалась музыка, а затем выполнялось ожидание длительностью 900 секунд.

На стороне сервера, принимающего звонки, велась запись разговора командой MixMonitor.

При таком сценарии были получены следующие результаты:

Рис.2. Зависимость загрузки процессора от количества параллельных звонков

Примечание*: Максимальное значение загрузки четырехядерного процессора в Ubuntu — 400% (по 100% на каждое ядро).

Рис. 3. График зависимости загрузки процессора от количества параллельных звонков

Мониторинг сети не выполнялся, но по нашей оценке, 100Mb сеть должна была выдержать не менее 1560 параллельных разговоров. Учитывая тот факт, что в тесте был достигнут предел загруженности процессора, а отличная слышимость сохранялась до нагрузки в 1626 параллельных звонков, пропускная способность сети не стала в этом случае ограничивающим фактором.

Слышимость оценивалась субъективно — при выполнении дополнительного звонка в ручном режиме. «Отличная» оценка слышимости при этом означает, что какие-либо искажения не были замечены.

При тестировании облачной инсталляции Asterisk, упоминавшейся выше, мы сравнивали загрузку процессора для двух вариантов ее источников: для случая реальных звонков и для моделирования нагрузки с помощью Wombat Dialer. В диапазоне до 20 параллельных звонков разница в загрузке процессора и памяти между реальными звонками и моделируемыми с помощью Wombat Dialer отличалась примерно на 1–2%.

Анализ результатов и выводы.

Представленные выше результаты демонстрируют, что IP-АТС Asterisk, установленная на процессоре Intel Xeon E5506 Quad-Core, способна обслуживать примерно до 1600 параллельных разговоров.

Отмечен характер зависимости, близкий к линейному (с отклонениями в пределах 8–10%). Такие отклонения могли быть вызваны случайными факторами, связанными как с влиянием вспомогательных процессов операционной системы, так и с выбором моментов фиксации значений загрузки CPU. Снятие этих значений выполнялось вручную, с выбором максимальной величины на некотором интервале наблюдения (порядка 10 сек.).

Однако, помимо упомянутых случайных отклонений, следует также учитывать возможные методологические (систематические) ошибки. Они могут быть связаны со следующими факторами:

1. Тестируемый Asterisk не выполнял соединений с установленными отдельно реальными телефонными аппаратами: все звонки принимались на один номер, при этом каналы с отдельными устройствами, установленными на других точках сети, не образовывались.

2. Медиапоток передавался в основном в одну сторону — в направлении от тестируемого сервера к серверу, создающему звонки. Однако он был непрерывным, а не периодическим. Можно предположить, что в целом создаваемая таким образом нагрузка была не ниже той, что имеет место при реальных разговорах, но ее характер был несколько отличным.

Оценить отрицательное влияние перечисленных факторов на достоверность полученных результатов в применении к реальной нагрузке затруднительно, однако мы предполагаем, что взяв значительный запас, можно вполне рассчитывать на то, что в инсталляции, обрабатывающей 800–1000 параллельных звонков, описанная конфигурация будет работать качественно и надежно.

Следующим важным выводом является то, что Asterisk полностью задействует вычислительную мощность всех имеющихся ядер, т.е. в нем реализован достаточно эффективный механизм балансировки нагрузки между этими ядрами. Таким образом, нагрузочная способность этой системы может быть увеличена за счет использования большей компьютерной мощности (повышения частоты процессора, использования большего числа ядер, а также применения многопроцессорных инсталляций).

В то же время потребление памяти находится на очень низком уровне и практически не зависит от нагрузки (при тестировании облачной инсталляции такая зависимость отмечалась, но в целом требуемый объем памяти гораздо ниже того уровня, который мы обычно имеем в реальных системах).

В этом тесте мы не ставили задачу моделирования всех разнообразных факторов, которые могут влиять на нагрузочную способность в реальных инсталляциях. К ним можно отнести, например, наличие транскодирования, влияние мониторинга очередей, наличие каких-либо средств интеграции Asterisk с прикладными системами, и многое другое.

Однако методика нагрузочного тестирования, изложенная в настоящей статье, может быть использована для выполнения сайзинга и тестирования нагрузочной способности для любых конкретных проектов — достаточно воссоздать те условия, которые будут характерными для тех или иных ситуаций.

Мы также рекомендуем в случаях, когда планируемая нагрузка может приближаться к 50% от предполагаемого максимума, подключать постоянный мониторинг загрузки CPU с выдачей алертов при превышении определенного порога. Наличие такого контроля позволит избежать сюрпризов в работе IP-АТС, связанных с ее перегрузкой.

Владимир К. Дудченко, Евгений Анваер (www.softbcom.ru)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.