1 | изначальная версия редактировать | |
еси необходимо ловить перегрузку по емкости, то лучше поставить "заглушку". если необходимо анализировать нагрузку, то, думаю лучше будет суммировать продолжительности разговоров в интервалы времени.
2 | No.2 Revision редактировать |
еси необходимо ловить перегрузку по емкости, то лучше поставить "заглушку". если необходимо анализировать нагрузку, то, думаю лучше будет суммировать продолжительности разговоров в интервалы времени.
О том, что Вы спросили на языке sql звучит так:
...where start_call between (dateA,dateB) and end_call between (dateA,dateB).
Но count() Вам здесь не в помощь, т.к. количество звонков за установленный интервал не является показательным для Вашей задачи. Т.е., Вы этим запросом посчитаете сколько было звонков в интервале между dateA и dateB. Думаю, что дальнейшему объяснению это логическое направление не подлежит...
Допустим у Вас N каналов. Максимальной нагрузке (занятости всех каналов) за установленный интервал (А,В) времени будет выражение (B-A)*N.
Адекватно суммируя продолжительности звонков, при этом, изменяя дискретность итераций в интервале, Вы получаете более или менее близкую к реалии кривую нагрузки. Где-то вот так...
3 | No.3 Revision редактировать |
еси необходимо ловить перегрузку по емкости, то лучше поставить "заглушку". если необходимо анализировать нагрузку, то, думаю лучше будет суммировать продолжительности разговоров в интервалы времени.
О том, что Вы спросили на языке sql звучит так:
...where start_call between (dateA,dateB) and end_call between (dateA,dateB).
Но count() Вам здесь не в помощь, т.к. количество звонков за установленный интервал не является показательным для Вашей задачи. задачи (кол-во одновременно занятых каналов). Т.е., Вы этим запросом посчитаете сколько было звонков в интервале между dateA и dateB. Думаю, что дальнейшему объяснению это логическое направление не подлежит...
Допустим у Вас N каналов. Максимальной нагрузке (занятости всех каналов) за установленный интервал (А,В) времени будет выражение (B-A)*N.
Адекватно суммируя продолжительности звонков, при этом, изменяя дискретность итераций в интервале, Вы получаете более или менее близкую к реалии кривую нагрузки. Где-то вот так...
4 | No.4 Revision редактировать |
еси необходимо ловить перегрузку по емкости, то лучше поставить "заглушку". если необходимо анализировать нагрузку, то, думаю лучше будет суммировать продолжительности разговоров в интервалы времени.
О том, что Вы спросили на языке sql звучит так:
...where start_call between (dateA,dateB) and end_call between (dateA,dateB).
Но count() Вам здесь не в помощь, т.к. количество звонков за установленный интервал не является показательным для Вашей задачи (кол-во одновременно занятых каналов). Т.е., Вы этим запросом посчитаете сколько было звонков в интервале между dateA и dateB. Думаю, что дальнейшему объяснению это логическое направление не подлежит...
Предлагаю другой путь...
Допустим у Вас N каналов. Максимальной нагрузке (занятости всех каналов) за установленный интервал (А,В) времени будет выражение (B-A)*N.(B-A)*N. Минимальная продолжительность разговора 1сек. Интервал времени 30мин
Максимальная нагрузка за этот период составляет N*30*60
. Просуммировав продолжительности звонков, начало и конец которых находится между началом и концом установленного интервала, добавив сумму продолжительности звонков, начало которых находится между интервалом, но конец больше, чем конец... тьфу, какие пошлости получаются... Второй суммой должны быть звонки, выпадающие концом... ага, из ширин... Ну, клин блинтон, надеюсь вы поняли... чтобы не выпалииии... не, не могу больше....
Не потеряйте звонки с неоконченными разговорами по отношению к интервалу.
Полученную сумму соизмерьте с максимальным значением. Вы получили среднее значение нагрузки за весь период.
Разделив интервал пополам и выполнив суммирование в каждой части, Вы получили первое приближение к действительному значению нагрузки. И так далее...
Адекватно суммируя продолжительности звонков, при этом, изменяя дискретность итераций в интервале, Вы получаете более или менее близкую к реалии реальной кривую нагрузки. Где-то вот так...
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.