Не нашел данного сабжа на этом ресурсе, поэтому решил открыть такую тему. Кто чем и как пробовал искусственно нагружать астер? Мне нужно протестить стабильность работы скрипта слушающего ивенты на AMI.
Я делал так, брал sipp и фигачил звонки на тестовый экстеншен. В самом экстеншене был набор типовых действий, которыми может заниматься телефонная система: проигрывание звуковых файлов и music on hold, обращение к MySQL (SELECT и INSERT), запись в текстовый файл, запись звонка в звуковой файл. Регулировал поток звонков от sipp и смотрелна загрузку процессора и прочие параметры системы, делал вывод о максимальной нагрузке. Еще оставлял поток звонков на длительное время (кажется, неделю) и наблюдал общую стабильность системы (падает или нет). Как-то так было.
определяли один экстеншн и просто разрешали на нем много одновременных звонков? А то сижу думаю создавать что ли кучу тестовых экстеншинов.
godlike ( 2015-04-22 12:23:46 +0400 )редактироватьВсе звонки валились на один экстеншен. Разрешать ничего не требовалось, это же не физический телефон.
glukinho ( 2015-04-22 12:28:29 +0400 )редактироватьЕще AGI добавьте, а внутри тоже что-нибудь этакое :)
glukinho ( 2015-04-22 12:43:06 +0400 )редактироватьsipp
?
подключение по AMI - это сетевое подключение. Т.е. вы можете написать сервер на любом языке программирования (от С до JS), который будет слушать порт 5038. При подключении к серверу сыпать в сетевое подключение кучу сообщений в формате AMI сообщений. Дальше только остается мерять производительность.
Если напишете сервер, выложите, пожалуйста, куда-нить, тоже потестирую. :)
не вижу ответа - читаем вопрос внимательнее ( у него уже есть скрипт, работающий с AMI)
Zavr2008 ( 2015-10-20 19:33:01 +0400 )редактироватьZavr2008, да, читаем вопрос внимательнее. Человек хочет протестировать не астериск, а скрипт, работающий с AMI, верно? Чтобы протестировать этот скрипт ему нужен AMI-сервер, который будет кидать в его скрипт евенты с заданной скоростью, это может быть астериск, а лучше сделать фейковый сервер, которому написать заведомый сценарий для кидания евентов в скрипт.
Подобный подход для тестирования AGI (не AMI : ) видел здесь: https://github.com/antirek/ding-dong/blob/master/test/index.js
obamo ( 2015-10-23 09:43:49 +0400 )редактироватьэмуляция никогда не доводила до добра, я думаю ТС не сам скрипт хотелось протестировать, а связку с Астером.
Zavr2008 ( 2015-10-29 21:30:52 +0400 )редактироватьМне нужно протестить стабильность работы скрипта слушающего ивенты на AMI.
Тогда логично сначала не сам SIP Asterisk тестить, а просто создавать достаточное кол-во таких эвентов чтобы пропустить через обработчик 10k-100к событий.
Например через Call файлы с рандомной длиной звонка и паузой и LOCAL в App какой.
Ну а далее уже и всю систему..
Еще можно так
там показано, как делать не надо. ибо есть субьективная оценка, а обьективная оценка не явлется таковой в связи с выбором железа(hetzner virtual server не показывает обьективно cpu)
meral ( 2015-04-27 20:31:26 +0400 )редактироватьЛюбое нагрузочное тестирование всегда будет субъективное.
Просто в отличии от sipp есть возможность генерирования локальных сценариев, например
переход по IVR, а вот например протестировать на нагрузку через PSTN вобще не
представляю, как можно реализаовать по другому.
bolshoy_plohish ( 2015-04-28 05:07:48 +0400 )редактироватьЧто касается бесполезности тестирования... обязательно нужно делать нагрузочное
тестирование... и не только перед запуском системы, но и учебные.
В большинстве более-мение торговых компаниях час простоя исчисляется миллионами.
bolshoy_plohish ( 2015-04-28 05:31:30 +0400 )редактироватьем. я боюсь вас расстроить, но sipp тоже позволяет сделать переход по ivr :) конкретно по ссылке пример крайне неудачный. ибо ничего вообще не говорит о реальности на той же платформе.
meral ( 2015-04-28 05:54:24 +0400 )редактироватьУ меня в системе несколько обработчиков событий написанных на PHP. Влияния на производительность не замечено. Валится все что приходит по AMI. Конечно нужно писать на чем-то более пригодном, но если не усердствовать в обработках то и пых справляется. Главное чтоб успевал обработать нужные события (пых однозадачен же). Еще пробовал писать в базу все AMI события, тоже на пыхе. Так же не заметил особых тормозов в реальных условиях (атом, 100 абонентов, Е1)
Задан: 2015-04-22 11:49:28 +0400
Просмотрен: 1,183 раз
Обновлен: Oct 19 '15
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
это бесполезно. как сказал один мудрый человек "не идин крипт не нажмет кнопки которые может случайно нажать юзер". вобщем результат на продакщене и в тестах отличается тут очень сильно. с тестами то ваш скрипт справится, почти 100%. обычно затыки на трансферах и всяких случайно набранных кодах типа *535*54
meral ( 2015-04-23 15:22:55 +0400 )редактироватьну тут больше идея проверить какой поток ивентов (количественно) сможет выдержать скрипт, мало ли, вдруг при потоке ивентов соответствующему например 10 звонкам он упадет. Кстати связанный вопрос, можно ли как то ами сказать, что бы сыпала например только ивенты Dial, Answer, Hangup?
godlike ( 2015-04-23 15:26:44 +0400 )редактироватьтам есть какието категории,но они странно работают. amiproxy вроде умеет фильтровать. категории переключаются вот так http://www.voip-info.org/wiki/view/Asterisk+Manager+API+Action+Events
meral ( 2015-04-23 23:32:48 +0400 )редактироватьсамый простой вариант - оставить только user и вставить userevents в dial, answer,hangup
meral ( 2015-04-23 23:33:47 +0400 )редактировать