типичная ситуация:
20 серверов астериск, realtime, и 10000 абонентов.
так вот вопрос:
зависит ли производительность одного сервера от кол-во записей в sippeers ?
есть ли какие-нибудь ограничения?

попутно второй вопрос:
как зависит производительность астериска от размера диалплана если он в realtime?

типичная ситуация :)
а поподробнее?
где-то встречал что для "типичного" сервера :) типично 5к реестраций, и всего 200-300 одновременных соединений без транскодинга... на одной конференции мне парили т.н. софтсвич который на Р4 Квадро держал(!?) 1000 одновременных соединений :)
ИМХО вопросы производительности Астериска- это вечный философский вопрос. Можно еще измерить производительность *бокса, но не Астера настроенного вручную. Да и то окажется на различных связках железа работа будет отличаться

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

интересует, если в sip.conf и extensions.conf будет по 100 тыс. строк, что произойдет с астером?

В моем понимании аккаунты хранятся в БД (скорость работы СУБД на чтение/запись), БД хранится на винте (опять же скорость чтения/записи)... Далее нужно рассматривать принципы работы Астериска с БД, с ОС, опять же с железом, учитывать все его ТТХ, оптимизации, баги, несовместимости
ну раз не зависят от железа и ПО... Тогда - "-Приборы? -300! -Что 300? -А что приборы?"

ИМХО количество sip peer'ов не влияет на производительность в случае Real-Time конфигурации этих пиров и также при условии что кэширование выключено и база имеет нормальные индексы на поиск пиров по имени и по ip.
В случае с dial-планом все очень даже может быть плохо так как я понимаю в случае real-time конфигурации при каждом поиске нового (exten,priority) идет запрос в базу - так что тем больше строчек в таком плане тем больше запросов в базу.
Хотя для точности нужно глянуть в код но пока делать это лениво.

Погляди логи, и поймешь, что зависит. SQL запросы будут стрелять как из пулемета. Поэтому тут два "горлышка":
1) Насколько надежно реализована на С "пулеметная лента": не заткнутся ли она от большого числа SQL запросов
2) Насколько шустро работает база: при регистрации Asterisk делает update, во всех остальных случаев select. При большом объеме запросов будут блокировки, поэтому как минимум надо будет прямые селекты переделать на селекты из view с параметром read uncommited (грязное чтение), и тогда исключаются блокировки на уровне базы.

по умолчанию mysql real-time engine у астериска страшный и ужасный.
Я бы написал отдельный res или app модуль и зарегил бы из него отдельный real-time engine и в нем бы уже делал все по собственному усмотрению - например обращение в базе но с кэшированием на N мин например. В этом случае селекты из базы шли бы только каждые N мин. А между ними импользовались бы кэшированные значения с поиском через нормальный хэш-мап которых так в астере не хватает. Ну еще добавил бы в CLI команду типа mysql invalidate cache ну и чтото подобное в manager'е бы добавил как отдельный action. Думаю это особенно актуально для real-time dial-плана.
Другими словами заменил бы "пулемет" с "лентой" на менее автоматическое оружие :-)

1) предполагается обычное применение механизма realtime
сейчас тупо в sip.conf (текстовый) затолкал 5 тыс. записей об абонентах, по 15 полей в каждом. проц p4 1.6 256RAM - никакой тормознутости с довеском из незарегеных абонентов не заметил.
2) диалплан предполагается делать в виде процедур-обработчиков данных из бд. вот пример обработчика для IVR:

[ivr]

exten => _X.,1,noop(--==IVR [${EXTEN}] for VPBX [${vpbx_id}]==--)

exten => _X.,n,noop(add record to cdr)

exten => _X.,n,Set(ARRAY(_ivr_actions_id, _ivr_enable_direct_dial, _max_calls)=${IVR_SETTINGS(${vpbx_id},${EXTEN})})

exten => _X.,n,goto(ivr-actions,s,1)



[ivr-actions]

exten => s,1,noop(--==IVR actions for VPBX ${vpbx_id}==--)

exten => s,n,noop(add record to cdr)

exten => s,n,Set(EXT=${EXTEN})

exten => s,n,goto(actions,1)



exten => _X,1,noop(--==IVR actions for VPBX ${vpbx_id}==--)

exten => _X,n,noop(add record to cdr)

exten => _X,n,Set(EXT=${EXTEN})

exten => _X,n,goto(actions,1)



exten => actions,1,noop(--==IVR actions for VPBX ${vpbx_id}==--)

exten => actions,n,noop(add record to cdr)

exten => actions,n,Set(i=1) 

exten => actions,n,Set(act_count=${IVR_ACTION_COUNT(${vpbx_id},${ivr_actions_id},${EXT})})

exten => actions,n,noop(${vpbx_id},${ivr_actions_id},${EXT})

exten => actions,n,While($[${i} <= ${act_count}]) 

exten => actions,n,exec(${IVR_ACTION(${vpbx_id},${ivr_actions_id},${EXT},${i})}) 

exten => actions,n,Set(i=$[${i} + 1]) 

exten => actions,n,EndWhile 

все, что начинается на "IVR_" - это func_odbc, простые селекты.
Другое дело, что селекты обращаются к таблице с записями многие-о-многим, хз как индекс правильно сделать, но об этом будет болеть голова у спецов по БД.
весь диалплан будет компактен, 2-3 тыщи сторок от силы, храниться может и в текстовом файле, и его размер не будет зависеть от кол-ва абонентов. в среднем на один звонок будет 1-2 SELECT`а.

PS: с подачи cron333 решил заняться веб-мордой к hostedpbx.

когда я думал о hostedpbx я хотел для оптимизации писать отдельный mysql engine для real-time ну и хранить через него peer'ов.
Весь dial-план хотел запихнуть в отдельный демон который бы обрабатывал AGI от астериска. В этом случае нет никаких проблем с хранением этого dial-плана да и формат для хранения можно придумать абсолютно любой .
Тут правда тоже есть засада - так как я думал о Fast-AGI а он требует 1 socket на один звонок - когда звонков много слишком перегружается tcp/ip стэк.

ну так значит 10000 аккунтов в sip для астериска не преграда?