Результаты нагрузочного тестирования

We use cookies. Read the Privacy and Cookie Policy

Результаты нагрузочного тестирования

Джошуа Колп (Joshua Colp) смог получить результаты, приведенные в табл. 2.2, используя процессор AMD Athlon64 X2 4200+ с 1 Гб оперативной памяти и жестким диском SATA емкостью 80 Гб и проводя тестирования по стандартному сценарию в приложении SIPp: простое установление соединения, воспроизведение аудиофайла (приложение Playback()) и некоторый небольшой период ожидания (Wait()). Обратите внимание на существенное снижение использования ресурсов ЦП при чтении данных из оперативной памяти по сравнению с чтением с жесткого диска. Это можно истолковать так, что ЦП ожидает данные, подлежащие обработке, перед передачей их в запрашивающий канал. Однако это всего лишь простой тест, и он никоим образом не отражает, какое количество вызовов сможет обрабатывать ваша система. Определить количество одновременных вызовов, которое может быть обработано при использовании конкретного диалплана и сочетания приложений, можно, только проведя нагрузочное тестирование системы.

Таблица 2.2. Пример результатов тестирования для стандартного сценария SIPp, использующего простые приложения Wait() и Playback(); SIPp отражает обратный медиа-поток Asterisk

Количество 330 330 550 одновременных вызовов Использование 149 14,8 57,6 ЦП, % Средняя нагрузка 49 25 60 Запоминающее Жесткий диск ОЗУ ОЗУ устройство

Для больших установок Asterisk функциональность обычно распределяют между несколькими серверами. Один или более центральных модулей будут заниматься обработкой вызовов; их дополнят один или более вспомогательных серверов, обслуживающих периферийные устройства (такие, как система баз данных, система голосовой почты, система конференц-связи, система управления, веб-интерфейс, межсетевой экран и т. д.). Asterisk, как и многие Linux-системы, может расширяться с ростом требований к ней: малая система, которая прекрасно справлялась со всеми задачами по обработке вызовов и обслуживанию периферийных устройств, может быть распределена между несколькими серверами, когда требования возрастут и превысят ее текущие возможности. Гибкость - основная причина, по которой Asterisk исключительно рентабельна для быстро растущего бизнеса; для нее не существует эффективного максимального или минимального размера, который следует учитывать при составлении сметы на покупку. Хотя масштабируемость свойственна большинству телефонных систем, до сих пор нам не приходилось слышать о системе, которая была бы настолько же гибкой, как Asterisk. Однако стоит отметить, что задача по проектированию распределенных систем Asterisk не по зубам новичку в Asterisk.

Тем, кто намерен настраивать распределенную систему Asterisk, рекомендуется изучить протокол DUNDi, архитектуру реального времени Asterisk (Asterisk Realtime Architecture, ARA), func_odbc и другие имеющиеся в распоряжении инструменты для работы с базами данных. Это поможет научиться извлекать из логики диалплана необходимые вашей системе данные, которые будут использоваться системой Asterisk. Это делает возможным существование универсального множества логик диалплана, которое может использоваться во множестве блоков. Тогда для масштабирования системы необходимо просто ввести в нее дополнительные блоки. Однако вопросы масштабирования выходят далеко за рамки данной книги, оставим это как упражнение для читателя. Некоторые инструменты, которые могут использоваться для масштабирования, рассмотрены в главе 12.