Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Нагрузочное тестирование Asterisk

0

Не нашел данного сабжа на этом ресурсе, поэтому решил открыть такую тему. Кто чем и как пробовал искусственно нагружать астер? Мне нужно протестить стабильность работы скрипта слушающего ивенты на AMI.

удалить закрыть спам изменить тег редактировать

спросил 2015-04-22 11:49:28 +0400

godlike Gravatar godlike flag of Ukraine
814 91 20 54

Comments

это бесполезно. как сказал один мудрый человек "не идин крипт не нажмет кнопки которые может случайно нажать юзер". вобщем результат на продакщене и в тестах отличается тут очень сильно. с тестами то ваш скрипт справится, почти 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 )редактировать

6 Ответов

1

Я делал так, брал sipp и фигачил звонки на тестовый экстеншен. В самом экстеншене был набор типовых действий, которыми может заниматься телефонная система: проигрывание звуковых файлов и music on hold, обращение к MySQL (SELECT и INSERT), запись в текстовый файл, запись звонка в звуковой файл. Регулировал поток звонков от sipp и смотрелна загрузку процессора и прочие параметры системы, делал вывод о максимальной нагрузке. Еще оставлял поток звонков на длительное время (кажется, неделю) и наблюдал общую стабильность системы (падает или нет). Как-то так было.

ссылка удалить спам редактировать

ответил 2015-04-22 12:20:56 +0400

glukinho Gravatar glukinho
661 4 3 11

Comments

определяли один экстеншн и просто разрешали на нем много одновременных звонков? А то сижу думаю создавать что ли кучу тестовых экстеншинов.

godlike ( 2015-04-22 12:23:46 +0400 )редактировать

Все звонки валились на один экстеншен. Разрешать ничего не требовалось, это же не физический телефон.

glukinho ( 2015-04-22 12:28:29 +0400 )редактировать

понял, спасибо за совет.

godlike ( 2015-04-22 12:30:05 +0400 )редактировать

Еще AGI добавьте, а внутри тоже что-нибудь этакое :)

glukinho ( 2015-04-22 12:43:06 +0400 )редактировать
1

sipp

?

ссылка удалить спам редактировать

ответил 2015-04-22 11:54:41 +0400

komrad123 Gravatar komrad123
3780 5 3 42
0

подключение по AMI - это сетевое подключение. Т.е. вы можете написать сервер на любом языке программирования (от С до JS), который будет слушать порт 5038. При подключении к серверу сыпать в сетевое подключение кучу сообщений в формате AMI сообщений. Дальше только остается мерять производительность.

Если напишете сервер, выложите, пожалуйста, куда-нить, тоже потестирую. :)

ссылка удалить спам редактировать

ответил 2015-10-19 18:34:11 +0400

obamo Gravatar obamo
115 12 1 9

Comments

не вижу ответа - читаем вопрос внимательнее ( у него уже есть скрипт, работающий с 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 )редактировать
0

Мне нужно протестить стабильность работы скрипта слушающего ивенты на AMI.

Тогда логично сначала не сам SIP Asterisk тестить, а просто создавать достаточное кол-во таких эвентов чтобы пропустить через обработчик 10k-100к событий.

Например через Call файлы с рандомной длиной звонка и паузой и LOCAL в App какой.

Ну а далее уже и всю систему..

ссылка удалить спам редактировать

ответил 2015-10-15 19:34:18 +0400

Zavr2008 Gravatar Zavr2008 flag of Russian Federation
2685 11 9 37
http://mh.otx.ru/
0

Еще можно так

ссылка удалить спам редактировать

ответил 2015-04-27 16:33:38 +0400

bolshoy_plohish Gravatar bolshoy_plohish
1358 21 16 37

Comments

там показано, как делать не надо. ибо есть субьективная оценка, а обьективная оценка не явлется таковой в связи с выбором железа(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 )редактировать
0

У меня в системе несколько обработчиков событий написанных на PHP. Влияния на производительность не замечено. Валится все что приходит по AMI. Конечно нужно писать на чем-то более пригодном, но если не усердствовать в обработках то и пых справляется. Главное чтоб успевал обработать нужные события (пых однозадачен же). Еще пробовал писать в базу все AMI события, тоже на пыхе. Так же не заметил особых тормозов в реальных условиях (атом, 100 абонентов, Е1)

ссылка удалить спам редактировать

ответил 2015-04-26 21:18:45 +0400

switch Gravatar switch
8334 11 7 91
http://lynks.ru/

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2015-04-22 11:49:28 +0400

Просмотрен: 486 раз

Обновлен: Oct 19 '15

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.