Отпор
Отпор — это северная star Microsoft eCDN для оценки качества просмотра.
Отпор определяется как любое количество времени, в течение которого зритель тратит буферизацию с неподвижным или без видео. Он вычисляется для каждого человека в процентах от полного времени сеанса: буферное время / (время воспроизведения + буфер-время). Сумма всех пользователей отпора усреднена и отображается на панелях мониторинга аналитики для каждого события и усреднена для выбранного диапазона времени в мини-приложении "Отказ".
Три процента или более считается плохим опытом.
Диапазон | Цветовое кодирование | Определение |
---|---|---|
>3% | Красный | Мы считаем, что более трех процентов являются плохим опытом, что требует расследования, когда представлена существенная база пользователей. |
<3% и >1% |
Желтый | Может рассматриваться от деградированного до относительного. Мы обнаружили, что обычно желтый диапазон является причиной для беспокойства только в том случае, если он находится в верхней части диапазона и только в том случае, если затрагивается большая или концентрированная группа. |
<1% | Зеленый | Считается хорошим опытом. Обычно мы видим отпор ниже 1 % в клиентской базе Microsoft eCDN. |
Microsoft eCDN предоставляет подробные метрики взаимодействия, такие как отказ, которые можно использовать для подтверждения отчетов о плохом взаимодействии с пользователем и определения область затронутых зрителей. Его также можно использовать для выделения слабых мест в сетевой среде, особенно при выполнении нагрузочного тестирования с автоматическим тестированием.
Ниже приведены сценарии, в которых отпор может быть полезной метрикой.
Распространенный первый шаг в устранении неполадок — определение возраста проблемы. Сравнивая процент отпора события с предыдущими событиями, можно увидеть отдельный шаблон во временном диапазоне. Вопросы, которые следует задать, могут включать в себя...
- Это отпор также наблюдается в предыдущих событиях или оно не является постоянным?
- Является ли это отпор новым событием?
- Если это так, что-то изменилось в сопоставлении подсети или конфигурации сети с момента последнего события с хорошим отказом. Если да, то что?
На этом снимке экрана мы наблюдаем правдоподобную согласованную проблему, начиная с определенной даты с более крупными событиями. Помимо размера события, рекомендуется наблюдать и другие общие признаки, такие как поставщик услуг Интернета или группа подсети.
На этом снимке экрана мы видим, что высокий отпор для крупнейшего события является новой проблемой, которая не присутствовала в предыдущих событиях. Хороший вопрос, чтобы задать здесь, является ли плохое отпор было испытано по всей зрительской базе или сосредоточены где-то.
Мы также видим, что последующие события меньшего размера в порядке, поэтому справедливо предположить, что причина относится к уникальной черте события, такой как его размер, время или другое свойство.
Отказ может быть вызван несоответствием сети за пределами нашего непосредственного контроля, например поставщиком услуг Интернета или сетью доставки содержимого с сиюминутным несоответствием службы. На панели мониторинга Детализация после фильтрации по конкретному событию и выбора измерения Разбивка групп мы проверяем график временной шкалы отпора на наличие визуальных шаблонов в разных группах.
На этом снимке экрана временной шкалы отпора для измерения Групп мы наблюдаем три момента в течение этого 90-минутного события, когда высокий отпор был обнаружен во всех группах этой крупной организации, в начале, в середине и в конце мероприятия. Этот эффект между организациями является сильным показателем источника проблемы, который в данном случае является сетью доставки содержимого организации; CDN, не следует путать с eCDN Майкрософт.
Как и на приведенном выше временная шкала снимке экрана, в этом примере мы также наблюдаем момент отпора в масштабах всей организации ближе к концу. Более того, мы также можем наблюдать, что одна из групп VPN этой организации испытывает плохое отпор на протяжении всего мероприятия. Это может быть явным признаком нехватки емкости в канале VPN организации. Если это так, эта группа будет хорошим тестом для изучения влияния разделенного туннелирования трафика Teams для снижения нагрузки.
Предполагая, что общая причина не очевидна, перейдите к процессу устранения неполадок, чтобы определить место проблемы, систематически срезов данных на различных доступных разбивках на панели мониторинга Детализации аналитики . Измерения разбивки включают следующие.
- Событие
- Группа
- Приложение
- ISP
- Страна
- Город
- ОС
Даже если передано сопоставление подсети, иногда места с высоким уровнем отпора можно найти в одной из групп по умолчанию. Чтобы устранить неполадки с плохими метриками для этих групп, используйте автоматически заполненные категории разбивки, например следующие, для фильтрации и среза данных.
- Приложение
- ISP
- Страна
- Город
В следующий раз, когда вы столкнулись с высоким отпором, найдите закономерности и задавайте себе вопросы, такие как ниже.
- Является ли высокий отпор происходит в масштабах всей компании или только на определенных участках?
- Является ли более высокий отпор для конкретных операционных систем или приложений, используемых для watch трансляции?
- Произошло ли отпор в определенную минуту для каждого пользователя и ушел через некоторое время?
- Существует ли корреляция между наблюдаемым моментом отпора и другим потенциально влияющим событием в сети?
Отказ является нежелательным побочным продуктом, обычно связанным с ненадежностью сети. С помощью панелей мониторинга Microsoft eCDN вы можете получить дополнительные сведения о его источнике, чтобы помочь вам решить эту проблему.