Загружается...
 
Производительность Asterisk систем

Производительность Asterisk систем


Типичные вопросы, которые можно увидеть в пользовательском списке рассылки asterisk-users, примерно такие:

Насколько быстрым и мощным должно быть аппаратное обеспечение моего сервера, чтобы он мог удовлетворять моим потребностям?
Сколько одновременных вызовов может обрабатывать сервер Asterisk?

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

  1. Какие типы телефонов Вы планируете использовать (обычные аналоговые, SIP, Skinny, H.323, MGCP)?
  2. Сколько телефонов Вы планируете подключить?
  3. Сколько линий во внешний мир у Вас имеется, и какая для них используется технология (аналоговая линия, BRI, PRI, T1, VoIP)?
  4. Сколько у Вас, примерно, ожидается внутренних/внешних одновременных вызовов (например: 30%)? Обратитесь к таблицам для вычисления Эрланга (параметр интенсивности обработки требований в системах массового обслуживания) (смотри ссылки ниже), если у Вас есть сомнения по этому вопросу.
  5. Какие голосовые кодеки будут у Вас использоваться, и будет ли у Вас необходимость в перекодировании из одного кодека в другой (транскодировании)? Tip: наберите команду: SHOW TRANSLATION в CLI консоли.
  6. Какие возможности и сервисы будет предоставлять ваша система (подавление эха, голосовая почта, конференции и очереди вызовов & call-центр, запись разговоров, факсы, голосовое меню, синтез и распознавание речи)?
  7. Насколько надежной/Asterisk at large|расширяемой должна быть Ваша система?
  8. Сколько серверов с Asterisk вы планируете использовать для Вашей задачи?
  9. Что поддерживается Вашей IP сетью из возможностей (скорость, поддержка QoS, VLAN, Power-over-Ethernet)?

Следующими шагом можно сделать следующее:
  • a) Посмотреть секцию: рекомендации по аппаратному обеспечению, и
  • b) после этого, если такое возможно, построить тестовую систему, которая сможет симулировать задачи, которые Вам требуются. Например, можно запустить тест загрузки с использованием .call фалов, которые генерируются неким скриптом.

Сколько вызовов сервер может обрабатывать одновременно?

Ниже приводиться коллекция отчетов из пользовательского списка рассылки "asterisk-users":

Замечание: Если у Вас возникнет желание что-то добавить в этот список, пожалуйста, используйте процент загрузки CPU и Памяти, а не параметр "load average". Это дает более конкретную информацию и имеет важное значение при сравнении разного аппаратного обеспечения и разных операционных систем. Записи отсортированы по мощности CPU.

  • Для старых и медленных CPU, смотри раздел: рекомендации по аппаратному обеспечению.
  • Основанный на Gumstix SIP-to-IAX прокси сервер может маршрутизировать около 40 вызовов одновременно (транскодинг кодеков не используется, Gumstix 400XM, голосовая почта располагается на CF карте)
  • Pentium 133 MHz, 16 Mb ram: Обарбатывает до 3 одновременных SIP вызовов без ухудшения качества (насчет использования транскодинга информации нет).
  • Linksys NSLU2, известный как "slug" (NAS Device ценой $79): Обрабатывает около 4 SIP вызовов с использованием кодеков g711 или gsm (но не с g729), с его процессором: IXP400.
  • Pentium 1, 166mhz, 32Mb ram: Успешно справился с четырьмя SIP вызовами с кодеком g711.
  • Pentium II 233/64 RAM: 2xBRI (4 ISDN канала) плюс несколько SIP устройств.
  • Процессор SC1100 на платформе Net4801 смог нормально декодировать только два голосовых потока с использованием G.729a кодека. Это, в общем, подтверждает, что серверу Asterisk требуется около 30 MHz процессорной мощности на каждый активный голосовой канал. Тогда 266 MHz CPU на платформе Net4801, теоретически, поддерживает около восьми одновременных вызовов. Подразумевается, что для всех вызовов используется голосовой кодек - G.711. Soekris Net4801, несмотря на то, что недорогой, довольно надежная платформа, предоставляет адекватную процессорную мощность для поддержки шести екстеншенов и до четырех активных канала связи одновременно.
  • (Май 2005) На Soekris board: безукоризненно транслировалось из G.729 IAX2 в G.729 SIP (может быть был включен IAX транк). Замечание: трансляции кодеков не производилось. Имелось, как минимум, ~30 вызовов в этой конфигурации (использовался AstLinux)
  • Soekris 4801 - может спокойно поддерживать 20 - 25 SIP клиентов, если они все используют одинаковый кодек (использовался ulaw). Известна конфигурация, где работало около 20+ sip клиентов и T1 карточка для zap канала, при этом все работало прекрасно. Если у Вас присутствует транскодирование между голосовыми кодеками, тогда soekris - это не Ваш выбор, но для небольших систем это неплохой вариант.
  • При количестве участников в конференции MeetMe: в 28 персон на машине с CPU Pentium II, 300MHz, 128 MB, vmstat показывает 70% простоя процессора.
  • "У меня имелось в течении дня от 15, до, максимум, 30 участников конференции, все из которых использовали одну и туже конфигурацию meetme. Asterisk работал на старой 4U 500Mhz машине (двухпроцессорная система с одним установленным CPU). За некоторыми исключениями, в виде проблем с некоторыми программными sip телефонами, данная реализация оказалась довольно безпроблемной."
  • Интегрированная VIA с 800 MHz CPU: Максимальное число одновременных вызовов с транскодированием кодеков, для протокола speex: 4, для ilbc: 9; для g729: 11, для g726: 22, для lpc10: 24, для gsm: 25, для A-law: 83
  • Asterisk 1.2 beta - очень неплохо обрабатывал SIP соединения: Был запущен Asterisk на 1 GHz Лэптопе и легко справлялся с 250 одновременными вызовами с переназначением RTP потоков между оконечными устройствами напрямую (re-invited). Все это потребовало всего около 9% процессорной мощности. а с трансляцией кодеков в RTP потоке (ulaw-alaw, простенькая задача) - этот лэптоп грузился на 99% при работе примерно с 50 вызовами...
  • Celeron 1GHz с 2 GB RAM обрабатывал 72 DID, 24 соединения с обычной АТС, и выступал в роли FAX сервера. (Использовалась версия Asterisk1.0.9)
  • Dual P3 1.13ghz, с пятью каналами в публичную сет через PRI -> G729 канал связи, имел постоянную загрузку, равную 0.45
  • Dual 1.266 PIII с 2 GB RAM обрабатывал 75-85 одновременных SIP сессий (GSM кодек) + 3 IAX2 транка, в общей сложности - около 100 вызовов одновременно (использовался Asterisk 1.0.9). Так же эта машина использовалась в качестве файлового сервера (с авторизацией по LDAP в Win2K ADS домене).
  • Intel P4 1.7G 512mg RAM, 20 gig HDD: с двумя картами T400P использовался, как точка входа телефонных соединений из вне и обрабатывал 60 аналоговых телефонов; по 24'м каналам PRI
  • (Апрель 2003) chan_h323: Появилась возможность работать в режиме сквозной передачи голосовой информации (codec pass-through) в Asterisk (в отличие от драйвера chan_oh323), но по прежнему не реализован "jitter" буфер. Мы сымитировали 125 одновременных запросов в случайных (15 секундных) интервалах, использование транзитной передачи голосового потока, на машине с 500mhz P4, дало результат, что эти запросы без осложнений удовлетворялись с задержкой не более 5 секунд. На той же машине было сымитировано 45 одновременных вызовов с использованием транскодирования GSM кодека, и снова без длинных задержек в процессе установки связи.
  • На сегодняшний день, мы добились потрясающего результата в 790 одновременно проигрываемых звуков. (протокол sip, любой кодек.) На PC ценой всего 350$. Тест прошел на машине: P-IV 2.4ghz с 512mb ram. Пока Вы не нагружаете CPU жадными до процессорного времени задачами, такими как транскодирование голосовых кодеков, Вы можете довести загрузку до 1% неактивности процессора без малейших сбоев в звуке, в данном тесте.
  • Celeron 2.4 GHz, 386 MB RAM, 1xT1 - использовался (только) для 10 телефонов
  • 2.6 GHz Pentium4 800MHz bus с HT технологией, 2 GB RAM (однако, 1 GB реально достаточно): 40 одновременных вызовов SIP-->ZAP (может и больше бы получилось): "Равномерно, в течении периода продолжительностью около 12 часов, а в течение дня общее количество вызовов достигает 5000. На данном сервере приблизительная загрузка (load average) прыгает от 0.00 до 6.25 в течение минуты"
  • Информация о производительности с использованием кодека g729, взятая с сайта Digium: Внутреннее тестирование с использованием dual Intel Xeon 1.8GHz CPU, позволяет совершать 60 одновременных вызовов. Dual Xeon с 2.8GHz CPU позволяет совершать 80 одновременных вызовов.
  • "Загрузка очень сильно зависит от того, что у Вас делается на сервере. Например, простая система с IVR/Zap и только одним T1 каналом может обрабатывать 10 одновременных вызовов в SIP&Zap конференции (как минимум, по моему опыту)."
  • P4-3Ghz/1Gb RAM: используется format_mp3 для музыки ожидания (MoH) на ОС FreeBSD 5.4 с CVS HEAD версией Asterisk (Июль 2005). Прекрасное качество декодирования mp3 файлов... до 70 процессов одновременно проигрываемой музыки ожидания (MoH) (8khz 16bit mono mp3), состояние нагрузки CPU - около 80% простоя.
  • (Август 05) Pentium 4 (без технологии HT) 3.0Ghz, 1 GB Ram. Обработал 46 SIP вызовов с кодеком G.711, при которых во все каналы произносились цифры, при помощи функции: SayDigits(1234567890). Приблизительно, загрузка (load average) составила: 0.43.
  • Мы проделали некоторые эксперименты по проверке производительности на машине с 3GHz HT CPU с 1GB RAM, с зеркалированными обычными IDE дисками. В машине были установлены карты: Digium quad-PRI, TDM40B, TDM22B и Sirrix quad-BRI. Этот сервер смог работать со 120 активными вызовами через 4 PRI канала. Сервер играл музыку ожидания (MusicOnHold) в 60 каналов, проигрывая некоторое приглашение в формате GSM в эти каналы. Использование процессора: "user" - около 25%, "system" - так же около 25%. (Мне кажется, что "system" часть нагрузки на процессор уменьшилась бы, если бы я убрал неиспользуемые карты). Я смог добавить до 5000 SIP регистраций и 5000 IAX2 регистраций - всего получилось около 100 попыток регистрации клиентов в секунду. Что добавило еще 40% пользовательской нагрузки на CPU, и он оказался полностью загружен. Качество аудиосигнала по-прежнему оставалось нормальным, хотя на PRI интерфейсе наблюдались небольшие прерывания. Загрузка (Load average) при этом прыгала между значениями 5 и 10. Объем трафика по ethernet интерфейсу, который генерировался регистрациями клиентов, составил: 550Kb/s исходящий и 400Kb/s входящий.
  • "Dual Xeon 3.06: 120 каналов (60 вызовов) по протоколу H.323, кодек G.729 - использовало 10% CPU, транскодирование кодеков не производилось"
  • "Находясь в поисках подходящей задачи для 'оценки производительности'. Мы провели некоторые обсуждения по этому поводу, но пока, практически, Вы не сможете обеспечить приемлемое качество звука при более чем 20-25 одновременных вызовов, когда в asterisk присутствует транскодирование голосовых кодеков и используется протокол H323." (замечание: может быть, это относиться только к драйверу oh323? Тест от Astertest для драйвера h323 показывает, что для кодеков, активно использующие CPU, например, g729, ilbc и speex, используемый протокол значения не имеет, следовательно, протоколы h323, sip и iax должны показать одинаковые результаты).
  • "Я где-то читал, что один человек испытал около 45 одновременных вызовов с использованием транскодирования кодеков. Возникает вопрос, если это все что может один сервер, зачем в этом случае брать карту 4 E1s Digium, когда она поддерживает 120 каналов, но сервер не может их обработать с транскодированием голосовых кодеков из VOIP в канал TDM?"
  • "У меня на практике получилось 100 каналов с кодеком G.729 на машине с dual 3.0ghz Xeon CPU. Цена вопроса: около $42 за канал (я купил SCSI подсистему с RAID, и включая $10 отчислений за лицензию на использование G.729 кодека.) (Не включая карту Digium 4 T1/E1) Ваша выгода может варьироваться в зависимости от производительности системы и цен. Цена решения на базе AS5300: около $110 за канал, и эта разница может использоваться при выборе оптимального по цене решения."
  • В своем тестировании я получил 200 одновременных вызовов на процессоре Xeon 2.4, используя SIPP, каждый вызов длился 10 секунд с периодичностью 20 входящих вызовов в секунду, использовался протокол SIP, а не Zap. У меня не было второго процессора, чтобы проверить надежду на то, чтобы получить, хотя бы не 400 вызовов для двухпроцессорной системы, но может быть хоть 350.
  • (Январь 2006) Сервер Dual Xeon 2.8 GHz Intel Chassis, 1GB RAM: Работал с +-35 IAX2 каналами, отправляя вызовы через 2 x PRI (E1) Digium Zap канала. Важно, что сервер записывал все вызовы и записывал все cdr записи в базу данных Mysql.
  • (Апрель 2005) Сервер Dell PowerEdge dual 3.2 GHZ XEON (32 bit), 2GB ram: Был сконфигурирован с использованием механизма realtime для екстеншенов, sip и iax клиентов, с использованием локального сервера mysql, 80% всех вызовов - это IAX <-> SIP вызовы без транскодирования голосовых кодеков и без использования буфера "jitter", и 20% от общего количества, это IAX <-> IAX перенаправлении вызовов, опять же без трансляции кодеков. Сервер не имел zap каналов. Итак, когда у меня имелась нагрузка из 100 одновременных вызовов , что подразумевает 200 одновременных каналов для IAX и SIP вызовов (где 80% - это вызовы по каналу IAX в канал SIP/RTP), тогда сервер asterisk использовал примерно 30% - 35% процессорного времени, а работа сервера mysqld вносила около 1% в загрузку всего сервера.. Итак, максимальное число вызовов, которое у меня получилось - около 300 ..
  • Один очень важный момент, который нужно учитывать, когда Вы говорите о вызовах SIP->Zap в Asterisk, это пиковая нагрузка на процессор. Возьмем среднюю машину с четырьмя процессорами, которая может быть и способна обрабатывать 200 одновременных разговоров в связке Sip->Zap, но, в реальности, будут возникать 4x пиковые максимальные нагрузки, которые будут случайно появляться в процессе разговора по каналу Sip->Zap, и которые могут привести к сбою всей Вашей системы, если появятся.
  • Сервер Asterisk может обрабатывать максимально только 250 одновременных ZAP каналов. Это связано с ограничением в 255 каналов, которое заложенно в драйвере ZAP. Дополнение (Сентябрь 2005): это ограничение было убрано уже ОЧЕНЬ давно. Драйвер Zaptel содержит другой интерфейс для открытия файлов устройств в количестве - ~250 или более, существующих в директории /dev/zap.
  • Mark Spencer, 29-11-2004: Я перевел IAXTel на использование механизма "realtime", но он по прежнему очень грузит систему, видимо из-за больших задержек. На данный момент имеется 6000 зарегистрированных пользователей, около 1000 из них, обычно, одновременно зарегистрированы на сервере iaxtel.
  • (Май 2005) Я тестировал CVS-HEAD Версию. Я смог получить 5551+ sip "сеансов", без прохождения медиапотока через asterisk, без всяких проблем (тестирование производилось с участием только одного SIP пользователя). Загрузка (load average) имела значение: 2-3. Замечание по поводу конфигурации... На моем 3ghz P4 HT сервере я могу получить 629 SIP вызовов с кодеком ulaw и медиапотоком, идущим через Asterisk (проверено), тоже без проблем. Загрузка (load average) сервера колебалась вокруг значения 14, и звук оставался безупречным... Итак, если у Вас имеется сервер с двумя процессорами 3.4 ghz Xeon, то у Вас не должно возникнуть проблем с использованием DS3 в asterisk. (Это в случае, если значение для прерываний установлено 1000 в секунду, а не 28000 и когда для вызовов используется кодек ulaw) ... заметьте, что если не установите лимит ulimit -n 100000 или другой, предназначенной для этого командой, перед запуском сервера asterisk, то у Вас количество файловых дескрипторов (FD) хватит, примерно, на 151 возов.
  • (Май 2005) Реальный барьер расширяемости системы, который я вижу, связан с количеством зарегистрированных в системе пользователей... Как много их выдержит один сервер (как минимум для IAX протокола). Я видел сообщения, что Dual Xeon 3.2GHz не может обрабатывать больше, чем 1000 IAX клиентов. ... Я сумел получить примерно 2500 одновременно работающих в системе пользователей на одном сервере, внеся некоторые модификации в файл iax2.h (время истечения периода регистрации было изменено с 60 до 240 секунд) нормальные IAX клиенты будут работать с этой установкой... Кстати, не делайте это значение более большим, потому что многие шлюзы с NAT будут удалять свои динамические записи для NAT трансляции через 300 секунд, а некоторые даже через 30 секунд!
  • (Май 2005) Пока Вы еще не можете обрабатывать 10k пользователей в Asterisk, Я смог. Даже больше, это реальность. Некоторые из этих систем - это очень простенькие сервера для обработки media, в то же время некоторые из них так же обрабатывают регистрации пользователей. В то же время, я согласен, что Asterisk нуждается в дополнительных средствах, которые помогают обрабатывать регистрацию пользователей и расширяют его масштабируемость. На данный момент, причина, по которой я еще использую SER прокси - это скорость обработки регистраций и распределение нагрузки. Asterisk же предоставляет все, что мне необходимо для обработки вызовов.
  • (Апрель 2005) "Signate Telephony Server 5000", с системой ввода/вывода со скоростью 51 Gb/sec поддерживает более чем 5,000 сеансов вызовов по протоколу SIP на один модуль, используя 80% емкости гигабитной сети. До 8 модулей расширения могут использовать соединительную шину, имеющую скорость 6.4GB/sec на основе технологии SGI, что позволяет управлять системой способной поддерживать более 40,000 одновременных потоков вызовов.



Определение предельной загрузки

То, что действительно важно - это нагрузка на Вашу систему и типы каналов, которые у Вас используются. Каналы Zap более надежно работают при предельной загрузке, чем любые из VOIP каналов. Действия по управлению могут не работать на предельных нагрузках. Все VOIP каналы более подвержены проблеме потери качества на предельной нагрузке. При максимальной нагрузке, имеется ввиду значение load average, равное 5.00 и выше (10.00 на машине с двумя CPU) , влияют еще и другие факторы. Нагрузка на систему, создаваемая используемыми каналами связи, различается от сервера к серверу, в зависимости от используемого CPU/RAM/Motherboard и от других приложений, запущенных на этом же сервере.

Аппаратное обеспечение от Digium (Июль 2005)

Карты компании Digium теперь стали более интеллектуальными! Компания Digium гордо анонсировала второе поколение firmware для своих многоканальных карт TE-серии для PCI шины. Это firmware позволяет использовать некоторые новые возможности. Они позволяют картам обрабатывать больше задач средствами аппаратного обеспечения самих карт, тем самым, разгружая центральный процессор для выполнения других действий, при этом, увеличивая его производительность, и давая возможность обрабатывать больше каналов связи, проходящих через один PC или сервер.
... При этом на 67% увеличивается производительность, по сравнению с предыдущими проверками ...

Новая версия firmware меньше полагается на центральный процессор сервера для решения задач обработки сигналов в картах Digium, тем самым уменьшая нагрузку на CPU и увеличивая производительность в целом и позволяя обрабатывать больше количество одновременных вызовов. Например, сервер с двумя процессорами 3-GHz 800FSB Intel XEON с кэшом 1MB L2, и с установленной картой Digium 4-port T1/E1, теперь могут конвертировать 120 SIP каналов с голосовым кодеком G.729 в публичную телефонную сеть без модуля подавления эха от Digium, и 150 каналов с голосовым кодеком G.729 при использовании модулей подавления эха компании Digium.

Если у Вас имеется очень большой трафик.

Scott Stingel www.evtmedia.com пишет:
Мой крупный клиент имел конфигурацию из 15 серверов asterisk, которая могла обрабатывать до 1800 одновременных вызовов с использованием системы голосового меню (IVR), Поступающих с большой местной АТС DMS-100, через 60 E1 каналов. Обычно, вызовы были очень короткими (5 секунд).
  • Я предложил: Использовать 1 процессор (шасси) (например: 2.8Ghz P4) для каждых из 4 каналов E1 (например: одна карта TE405P), когда имеется большое число попыток установки соединения. Я попробовал использовать dual-Xeon, дабы посмотреть, сможет ли он нормально работать с двумя картами TE410P, вместо одной, в системе, где используется только голосовое меню - IVR, но множество вызовов стало отбрасываться при максимальной нагрузке. Таким образом, я определил, что в один сервер можно максимально поместить по одной карте TE410 или TE405. Если у Вас производиться ограниченное количество процессов транскодирования голосовых кодеков, и не имеется большого числа вызовов, то Вы можете получить более чем 120, используемых одновременно, каналов в системе, но подходите к этому вопросу осторожно! А так же, я произвел новое тестирование, с использованием нового firmware для карт Digium, смотри текст выше.
  • В максимальной степени используйте возможности плана набора (extensions.conf). AGI скрипты предоставляют широкие возможности, но ценой этого является уменьшение производительности, когда Вы используете скрипты с большим количеством строк. (Для дополнительной информации, смотри: designers' FAQ #2)
  • По поводу, какой процессор использовать, смотри страницы Wiki, посвященные этому вопросу. Я успешно использовал для этих целей процессоры P4 и Xeon на платформах с материнской платой от Tyan и Intel.

512 одновременных вызовов SIP--SIP с Цифровой записью разговоров.

Как использовать RAM диск для устранения дефицита ресурсов системы ввода/вывода, связанного с использованием цифровой записи вызовов с помощью функции Monitor.
Аппаратное обеспечение для сервера Asterisk: Quad Xeon MP CPU 3.16 GHz с 20 GB RAM.

Тестирование нагрузки - Zap каналы

Scott Stingel: Вы можете построить тестовую систему для Zap каналов в asterisk, с использованием .call файлов (смотри: sample.call). Вот, что было найдено:

(a) Я не думаю, что это управление очередью нормально работает, если существует ограничение на количество ресурсов, которые используются для совершения исходящих вызовов. Например, если Вы определите группу (например, "g9"), в которую входят две линии для совершения исходящих вызовов, все это будет работать прекрасно, если число одновременных исходящих вызовов никогда не будет превышать двух. Третий call-файл, в данном примере, будет прочитан сервером, но его обработка сразу же закончиться с ошибкой. Итак, я сделал механизм в моем Perl скрипте для гарантии того, что предыдущий вызов был полностью завершен - это было сначала не так то просто, т.к. я не знал точно, когда наступает этот момент, но обработка в perl скрипте этих событий делает данную задачу проще.

(b) Существует проблема, связанная с одновременным созданием файлов в директории для формирования исходящих вызовов. При более чем 12-15 исходящих вызовов одновременно, естественно, если есть достаточное число каналов для совершения исходящих вызовов. Asterisk будет считывать их, но не сможет обработать некоторые фалы. Это сценарий для тестирования производительности, и, наверно, не очень реалистичный, но кое-что он позволяет проверить. Это не очень критично было для меня, если я использовал более мощный процессор. Отметьте, что эта проблема возможно уже решена (смотри текст далее).

Jesse Janzer: Краткая заметка, Мы реализовали систему для пейджинга и одновременно размещали более чем 30 файлов в директории для исходящих вызовов (в процессе выполнения agi скрипта), для совершения вызовов, проблем замечено не было...

Возможность использования директории и помещения туда .call файлов для совершения исходящих вызовов работает нормально при небольших количествах вызовов, если Вы равномерно создаете файлы в этой директории.

Фишка: Вы можете управлять временем начала совершения исходящего вызова, установив значение параметра mtime в Вашем .call файле. Смотри пример простого скрипта по ссылке: http://www.fnords.org/~eric/asterisk.

Тестирование производительности карт Quad T1 - Digium против Sangoma


Тестирование нагрузки - IP каналы.

Juanjo: Не забудьте увеличить максимальное число файловых дескрипторов и RTP портов.
Используется приложение SIPP.

Тест 1:
Я достиг значения в 1500 одновременных SIP/GSM вызовов, на екстеншен, где используется приложение Echo, с периодичностью в 50 вызовов в секунду и продолжительностью в 10 секунд, при использовании машины с одним процессором Xeon 2.4Ghz. Так или иначе, но Я пытался создать более менее реальный сценарий, полагая, что команда Echo не сильно занимается обработкой звукового потока, а просто копирует его из входящего канала в исходящий.
В процессе тестирования Я мониторил сервер Asterisk используя аппарат Cisco 7960, прослушивая музыку ожидания (MusicOnHold), примерно при количестве одновременных вызовов 500-600 начали наблюдаться перерывы в проигрывании музыки ожидания.

Тест 2:
Я настроил клиента (UAC) на генерацию вызовов с частотой 10 вызовов в секунду и продолжительностью 10 секунд и соответствующих вызываемых абонентов (UAS), которые отвечали на эти вызовы. Команда, которая использовалась для генерации вызовов с использованием кодека GSM, была следующая:
sipp 192.168.65.100 -s 700 -sf uac.xml -d 10000 -r 10

Команда для приема вызовов на другом сервере была такая:
sipp -sf uas.xml

Я использовал свои файлы uac.xml и uas.xml для работы с кодеком GSM, Мониторя качество звука на моем телефоне: Cisco 7960, прослушивая музыку ожидания (MusicOnHold). На моем процессоре Xeon 2.4Ghz, все вызовы обрабатывались нормально, и не было ни каких проблем с качеством прослушиваемой музыки. Обратите внимание, что у меня использовались настройки: nat=yes и canreinvite=no для вызывающего и вызываемого клиента (UAC/UAS), в файле конфигурации sip.conf. Старые версии приложения SIPP не поддерживают авторизацию.
  • В конфигурации: 40 вызовов в секунду с продолжительностью в 10 секунд (что подразумевает 400 одновременных вызовов) все у меня работало прекрасно.
  • В конфигурации: 50 вызовов в секунду с продолжительностью в 10 секунд, вызовы не отбрасывались, но стала появляться повторная передачи некоторых SIP пакетов.
  • В конфигурации: 60 вызовов в секунду, некоторое число вызовов было отброшено, но забавно, что это никак не сказалось на качестве аудиопотока, который прослушивался через телефон Cisco 7960.

Однако: Я не видел никакого RTP трафика, который бы шел с SIPP в роли вызывающего клиента (UAC), это говорит, что Asterisk вообще не генерирует трафика, после того, как он синхронизируется с сеансом, по которому поступил вызов AFAIK. Таким образом, может быть эти тесты и не измеряют общую производительность Asterisk, а только возможности стека протокола SIP. Другое решение - это направление всех вызовов в екстеншен с приложеним MusicOnHold, тогда весь трафик будет проходить через сервер Asterisk, что даст более взвешенный и полный результат.

Olle E Johansson сообщает свои результаты тестирования - свыше 10 000 одновременных вызовов!

В процессе замены большой устаревшей системы Nortel на несколько современных 1U-2U серверов было проведено множество тестов производительности новой системы, чтобы ответить на вопрос - как много вызовов обрабатывает один Asterisk сервер, в пересчёте на удельную себестоимость в евро?

Сначала обычным образом была достигнута производительность примерно в 2000 каналов при G.711 (64 Кбит * 2000 = 128 Мбит) на одном quad core процессоре и сетевой карте Intel Pro/1000 на сервере IBM. На этом этапе наблюдалась неустойчивая работа балансировщика IRQ, что приводило к пропусканию всего траффика только через одно ядро процессора. Этот тест проделывался несколько раз на нескольких системах с различными сетевыми интерфейсами, для того чтобы различными способами повысить производительность - с другими драйверами, другими картами, другим аппаратным обеспечением, но все признаки говорили о том, что проблема лежит в области обработки сетевого трафика RTP Астериск посредством CPU. Что также подтверждалось несколькими другими независимыми группами разработчиков.

И для меня стало неожиданным приятным сюрпризом в понедельник (24 августа 2009), когда мы проинсталлировали простую рабочую версию Asterisk 1.4 на новый HP Proliant DL380 Generation 6 сервер, и сделали циклические тесты на старые сервера IBM. Три сервера запетлевали звонки между собой, и общее количество одновременных вызовов достигло таким образом 10 000 каналов без каких-либо проблем! Соединения SIP to SIP, в режиме point-2-point RTP bridge, в основном с проксированием медиа. На этот момент наш дешёвый гигабитный коммутатор работал на пределе возможностей, также и сетевые интерфейсы. Замеры показывали примерно до 850 Мбит траффика на порт, что более, чем достаточно. Все CPU (а их было 16 вместе с hyperthreading) не были даже в пиковой загрузке, Астериск занимал некоторую часть наиболее правильным образом, но было ещё достаточно резерва, чтобы ещё запустить какие-то другие процессы в обработку.


Замечания
  • Перекодирование из одного голосового кодека в другой (транскодирование) потребляют много ресурсов процессора (интенсивное использование CPU), то же самое можно сказать и о процессе подавлении эха.
  • На использование голосового кодека g729 в Asterisk можно приобрести лицензию, тогда как лицензия на использование кодека g723.1 - не доступна, по этому Asterisk позволяет использовать этот кодек только в режиме прозрачной передачи (pass-thru).
  • Транковые каналы для протокола IAX могут помочь существенно уменьшить сетевой трафик, при использовании 3 или более одновременных вызовов между двумя серверами Asterisk.
  • Технология Hypterthreading не очень хорошо реализована в ядре 2.4.x; новая версия ядра 2.6.x более пригодна к использованию с технологией HT.

Таблицы для расчета Erlang'а

Расчет количества внешних телефонных линий, которые могут Вам понадобиться,

Ссылки по теме:


Оригинал: http://www.voip-info.org/wiki/view/Asterisk+dimensioning


Создано admin. Последнее изменение: четверг 27 / август, 2009 11:52:34 MSD автор ded.
История Комментарии