Настройка производительности Office 365 с помощью базовых показателей и истории производительности

Существует несколько простых способов проверка производительности подключения между Office 365 и бизнесом, которые позволят вам установить приблизительные базовые показатели подключения. Зная историю производительности подключений к клиентскому компьютеру, вы сможете обнаружить возникающие проблемы на ранней стадии, выявить и спрогнозировать проблемы.

Если вы не привыкли работать над проблемами с производительностью, эта статья поможет вам рассмотреть некоторые распространенные вопросы. Как узнать, что возникающая проблема связана с производительностью, а не инцидентом службы Office 365? Как можно планировать хорошую производительность в долгосрочной перспективе? Как следить за производительностью? Если ваша команда или клиенты видят низкую производительность при использовании Office 365, и вы задаетесь вопросом о любом из этих вопросов, читайте дальше.

Важно!

Возникла проблема с производительностью между клиентом и Office 365 прямо сейчас? Выполните действия, описанные в плане устранения неполадок с производительностью для Office 365.

Что следует знать о производительности Office 365

Office 365 живет в выделенной сети Майкрософт с высокой емкостью, которая отслеживается автоматизацией и реальными людьми. Частью поддержки Office 365 облака является настройка производительности и оптимизация там, где это возможно. Так как клиентам Office 365 облака приходится подключаться через Интернет, продолжаются усилия по точной настройке производительности в Office 365 службах.

Повышение производительности никогда не останавливается в облаке, поэтому ни один из случаев не обеспечивает работоспособность и скорость работы облака. Если у вас возникли проблемы с производительностью при подключении из вашего расположения к Office 365, лучше не начинать с или ждать обращения в службу поддержки. Вместо этого следует начать изучение проблемы с "наизнанку". То есть, начните внутри вашей сети и проработайте свой путь, чтобы Office 365. Прежде чем обращаться в службу поддержки, можно собрать данные и выполнить действия, которые будут изучать и устранять проблему.

Важно!

Помните о планировании ресурсов и ограничениях в Office 365. Эта информация будет выдвигать впереди при попытке устранить проблему с производительностью. Ниже приведена ссылка на описания служб Microsoft 365 и Office 365. Это центральный центр, и все службы, предлагаемые Office 365, имеют ссылку на собственные описания служб отсюда. Это означает, что если вам нужно просмотреть стандартные ограничения для SharePoint, например, щелкните Описание службы SharePoint и найдите его раздел Ограничения SharePoint.

Обязательно ознакомьтесь с устранением неполадок, понимая, что производительность — это скользящее масштабирование. Речь не о достижении идеализированной ценности и поддержании ее постоянно. Случайные задачи с высокой пропускной способностью, такие как подключение большого числа пользователей или выполнение миграции больших объемов данных, будут напряженными, поэтому планируйте влияние на производительность. Вы должны иметь приблизительное представление о целевых показателях производительности, но многие переменные играют в производительность, поэтому производительность зависит от.

Устранение неполадок с производительностью не относится к достижению определенных целей и поддержанию этих чисел на неопределенный срок, а об улучшении существующих действий с учетом всех переменных.

Ладно, как выглядит проблема с производительностью?

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

Инциденты службы происходят, когда у самой службы Office 365 возникают проблемы. В разделе Текущая работоспособность в Центр администрирования Microsoft 365 могут отображаться красные или желтые значки. Вы можете заметить, что производительность клиентских компьютеров, подключающихся к Office 365, работает медленно. Например, если текущий отчет о работоспособности отображается красным значком и отображается пункт Исследование рядом с Exchange, вы также можете получать звонки от сотрудников вашей организации, которые жалуются на то, что почтовые ящики клиентов, использующие Exchange Online, работают медленно. В этом случае разумно предположить, что производительность Exchange Online стала жертвой проблем со службой.

На этом этапе администратору Office 365 следует проверка Текущее состояние работоспособности, а затем часто просматривать сведения и журнал, чтобы поддерживать актуальность обслуживания в системе. Панель мониторинга Текущей работоспособности была создана для обновления об изменениях в службе и проблемах в ней. Заметки и объяснения, написанные в журнале работоспособности, администратору и администратору, помогут вам оценить и держать вас в курсе текущей работы.

Проблема с производительностью не является инцидентом службы, хотя инциденты могут привести к снижению производительности. Проблема с производительностью выглядит следующим образом:

• Проблема с производительностью возникает независимо от того, что центр администрирования Текущая работоспособность сообщает для службы.

• Поведение, которое используется для выполнения потока, занимает много времени или никогда не завершается.

• Вы также можете реплицировать проблему или знать, что она возникает, если выполнить правильный ряд действий.

• Если проблема возникает периодически, шаблон все равно может быть. Например, вы знаете, что к 10:00 у вас будут звонки от пользователей, которые не всегда могут получить доступ к Office 365. Вызовы завершатся около полудня.

Этот список, вероятно, звучит знакомо; может быть, слишком знакомо. Как только вы узнаете, что это проблема с производительностью, возникает вопрос: "Что вы будете делать дальше?" Оставшаяся часть этой статьи поможет вам определить именно это.

Определение и проверка проблемы с производительностью

Проблемы с производительностью часто возникают со временем, поэтому определить фактическую проблему может быть сложно. Create хорошее решение проблемы с хорошим представлением о контексте проблемы, а затем вам потребуется повторяемые шаги тестирования. Ниже приведены некоторые примеры операторов проблем, которые не предоставляют достаточно информации:

• Переключение с моего почтового ящика на мой календарь раньше было чем-то, что я не заметил, а теперь это кофе-брейк. Можете ли вы заставить его вести себя так, как раньше?

• Отправка файлов в SharePoint занимает вечное время. Почему это медленно во второй половине дня, но в любое другое время, это быстро? Не может ли это быть просто быстро?

Существует несколько серьезных проблем, связанных с приведенными выше заявлениями о проблеме. В частности, слишком много неоднозначности для решения. Например:

• Неясно, как переключение между папкой "Входящие" и "Календарь" используется для работы на ноутбуке.

• Когда пользователь говорит: "Не может ли это просто быть быстрым", что такое "быстрый"?

• Сколько времени "навсегда"? Это несколько секунд? Или много минут? Или пользователь может взять обед, и действие завершится через 10 минут после того, как он вернулся?

Администратор и средство устранения неполадок не могут знать сведения о проблеме из общих инструкций, таких как эти. Например, они не знают, когда возникла проблема. Средство устранения неполадок может не знать, что пользователь работает из дома и видит медленное переключение в домашней сети. Кроме того, пользователь запускает другие приложения с большим объемом ОЗУ на локальном клиенте. Администраторы могут не знать, что пользователь работает под управлением более старой операционной системы или не выполнял последние обновления.

Когда пользователи сообщают о проблеме с производительностью, необходимо собрать много сведений. Получение и запись сведений называется определением проблемы. Ниже приведен базовый список областей, который можно использовать для сбора сведений о проблемах с производительностью. Этот список не является исчерпывающим, но это место для начала:

• В какой день возникла проблема и в какое время дня или ночи?

• Какой клиентский компьютер вы использовали и как он подключается к бизнес-сети (VPN, проводной, беспроводной)?

• Вы работали удаленно или находились в офисе?

• Вы пробовали те же действия на другом компьютере и видели то же самое поведение?

• Выполните шаги, которые повысят проблему, чтобы вы могли написать выполняемые действия.

• Насколько медленно в секундах или минутах производительность?

• Где вы находитесь в мире?

Некоторые из этих вопросов более очевидны, чем другие. Большинство людей понимают, что средство устранения неполадок нуждается в точных шагах для воспроизведения проблемы. В конце концов, как еще можно записать, что не так, и как еще можно проверить, устранена ли проблема? Менее очевидны такие вещи, как "Какая дата и время вы видели проблему?" и "Где в мире вы находитесь?", информация, которую можно использовать в тандеме. В зависимости от того, когда пользователь работал, разница во времени в несколько часов может означать, что обслуживание уже выполняется в некоторых частях сети вашей компании. Например, ваша компания имеет гибридную реализацию, например гибридную Поиск SharePoint, которая может запрашивать поисковые индексы в SharePoint в Microsoft 365 и локальном экземпляре SharePoint Server 2013. Обновления могут выполняться в локальной ферме. Если ваша компания находится в облаке, обслуживание системы может включать добавление или удаление сетевого оборудования, развертывание обновлений для всей компании, внесение изменений в DNS или другую базовую инфраструктуру.

При устранении проблем с производительностью это немного похоже на место преступления, вы должны быть точными и наблюдательными, чтобы сделать какие-либо выводы из доказательств. Для этого необходимо получить хорошее заявление о проблеме, собирая доказательства. Он должен включать в себя контекст компьютера, контекст пользователя, когда возникла проблема, и точные шаги, которые выявили проблему с производительностью. Эта проблема должна быть самой главной страницей в заметках и оставаться в ней. Повторно пройдя инструкцию по проблеме после работы над решением, вы выполняете действия, чтобы протестировать и проверить, удалось ли устранить проблему с помощью выполняемых действий. Это очень важно для того, чтобы знать, когда ваша работа будет выполнена.

Знаете ли вы, как производительность выглядела, когда она была хорошей?

Если тебе не повезло, никто не знает. Ни у кого не было номеров. Это означает, что никто не может ответить на простой вопрос "О том, сколько секунд, сколько секунд занимает, чтобы получить папку "Входящие" в Office 365?" или "Сколько времени это занимало, когда руководители провели собрание Lync Online?", который является распространенным сценарием для многих компаний.

Здесь не хватает базовых показателей производительности.

Базовые показатели предоставляют контекст для вашей производительности. В зависимости от потребностей вашей компании следует иногда использовать базовые показатели. Если вы являетесь крупной компанией, ваша команда по эксплуатации может уже взять базовые показатели для вашей локальной среды. Например, если вы исправите все серверы Exchange в первый понедельник месяца и все серверы SharePoint в третий понедельник, ваша операционная группа, вероятно, имеет список задач и сценариев, которые она выполняет после исправления, чтобы доказать работоспособность критически важных функций. Например, откройте папку "Входящие", щелкните Отправить и получить и убедитесь, что папки обновлены, или в SharePoint перейдите на страницу main сайта, перейдите на страницу корпоративного Поиск и выполните поиск, который возвращает результаты.

Если ваши приложения находятся в Office 365, некоторые из наиболее фундаментальных базовых показателей можно измерять время (в миллисекундах) от клиентского компьютера в сети до точки исходящего трафика или точки выхода из сети и выхода в Office 365. Ниже приведены некоторые полезные базовые показатели, которые можно изучить и записать:

• Определите устройства между клиентским компьютером и точкой исходящего трафика, например прокси-сервером.

  • Вы должны знать свои устройства, чтобы иметь контекст (IP-адреса, тип устройства и т. д.) для возникающих проблем с производительностью.

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

  • Существуют сторонние средства, которые могут обнаруживать и сопоставлять вашу сеть, но самый безопасный способ узнать о своих устройствах — спросить у члена вашей команды сети.

• Определите поставщика услуг Интернета( ISP), запишите его контактные данные и спросите, сколько каналов у вас есть пропускная способность.

• Внутри вашей компании определите ресурсы для устройств между клиентом и точкой исходящего трафика или найдите контакт для экстренного реагирования, чтобы обсудить проблемы с сетью.

Ниже приведены некоторые базовые показатели, которые могут быть рассчитаны простым тестированием с помощью средств.

• Время от клиентского компьютера до точки исходящего трафика в миллисекундах

• Время от точки исходящего трафика до Office 365 в миллисекундах

• Расположение в мире сервера, который разрешает URL-адреса для Office 365 при просмотре

• Скорость разрешения DNS вашего поставщика услуг Интернета в миллисекундах, несоответствия в поступлении пакетов (сетевой дрожь), время отправки и скачивания в миллисекундах

Если вы не знаете, как выполнить эти действия, мы рассмотрим более подробно в этой статье.

Что такое базовые показатели?

Вы будете знать влияние, когда это будет плохо, но если вы не знаете свои исторические данные о производительности, невозможно иметь контекст для того, насколько это могло быть плохо, и когда. Таким образом, без базового плана, вы не хватает ключевой подсказки для решения головоломки: рисунок на поле головоломки. Для устранения неполадок с производительностью требуется точка сравнения. Простые базовые показатели производительности несложно. Вашей рабочей группе можно поручить выполнение этих задач по расписанию. Например, предположим, что подключение выглядит следующим образом:

Это означает, что вы проверили свою команду сети и узнали, что вы покидаете свою компанию в Интернете через прокси-сервер, и что прокси-сервер обрабатывает все запросы, которые клиентский компьютер отправляет в облако. В этом случае следует нарисовать упрощенную версию подключения со списком всех промежуточных устройств. Теперь вставьте средства, которые можно использовать для проверки производительности между клиентом, точкой исходящего трафика (где вы покидаете сеть в Интернет) и Office 365 облаком.

Параметры перечислены как Простой и Расширенный из-за объема знаний, необходимых для поиска данных о производительности. Трассировка сети займет много времени по сравнению с запуском средств командной строки, таких как PsPing и TraceTCP. Эти два средства командной строки были выбраны из-за того, что они не используют пакеты ICMP, которые будут заблокированы Office 365, и потому, что они дают время в миллисекундах, необходимое для выхода из клиентского компьютера или прокси-сервера (если у вас есть доступ) и получения Office 365. Каждый отдельный прыжок с одного компьютера на другой в конечном итоге будет со значением времени, и это отлично подходит для базовых показателей! Не более того, эти средства командной строки позволяют добавить номер порта в команду. Это полезно, так как Office 365 обменивается данными через порт 443, который используется протоколом SSL и TLS. Однако другие сторонние средства могут быть лучшим решением для вашей ситуации. Корпорация Майкрософт не поддерживает все эти средства, поэтому, если по какой-либо причине вы не можете работать PsPing и TraceTCP, перейдите к трассировки сети с помощью такого средства, как Netmon.

Вы можете взять базовый план до рабочего времени, снова во время интенсивного использования, а затем снова в нерабочее время. Это означает, что у вас может быть структура папок, которая выглядит примерно так:

Также следует выбрать соглашение об именовании файлов. Ниже приводятся примеры:

• Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

• Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

• Feb_08_2015_2pmEST_PerfBaseline_BADPerf

• Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

Это можно сделать разными способами, но использовать формат <dateTime><, что происходит в тесте> , — это хорошее начало. Старательное решение этой проблемы поможет вам, когда вы попытаетесь устранить неполадки позже. Позже вы сможете сказать: "Я взял два следа 8 февраля, один показал хорошую производительность, а второй показал плохой, так что мы можем сравнить их". Это полезно для устранения неполадок.

Вы должны иметь организованный способ хранения исторических базовых показателей. В этом примере простые методы создали три выходных данных командной строки, а результаты были собраны в виде снимков экрана, но вместо этого у вас могут быть файлы сетевого захвата. Используйте метод, который лучше всего подходит для вас. Храните свои исторические базовые показатели и ссылайтесь на них в тех случаях, когда вы заметите изменения в поведении веб-службы.

Зачем собирать данные о производительности во время пилотного проекта?

Нет лучшего времени для создания базовых показателей, чем во время пилотного запуска службы Office 365. В вашем офисе могут быть тысячи пользователей, сотни тысяч или пять, но даже с несколькими пользователями можно выполнять тесты для измерения колебаний производительности. В случае с крупной компанией репрезентативная выборка из нескольких сотен пользователей, пилотируемых Office 365, может быть спроецирована на несколько тысяч, чтобы вы знали, где могут возникнуть проблемы, прежде чем они произойдут.

В случае с небольшой компанией, где подключение означает, что все пользователи одновременно переходят в службу и нет пилотного проекта, сохраните показатели производительности, чтобы у вас были данные, чтобы показать всем, кому может потребоваться устранить неполадки при плохом выполнении операции. Например, если вы заметили, что вдруг вы можете обойти свое здание в течение времени, необходимого для отправки рисунка среднего размера, где она раньше происходила быстро.

Сбор базовых показателей

Для всех планов устранения неполадок необходимо как минимум определить следующие компоненты:

• Клиентский компьютер, который вы используете (тип компьютера или устройства, IP-адрес и действия, вызвавшие проблему);

• Где находится клиентский компьютер в мире (например, будь то пользователь в VPN-подключении к сети, удаленно работает или в интрасети компании);

• Точка исходящего трафика, которую использует клиентский компьютер из вашей сети (точка, в которой трафик покидает ваш бизнес для поставщика услуг Интернета или Интернета).

Структуру сети можно узнать у администратора сети. Если вы работаете в небольшой сети, посмотрите на устройства, подключающие вас к Интернету, и позвоните своему поставщику услуг Интернета, если у вас есть вопросы о макете. Create рисунок окончательного макета для справки.

В этом разделе представлены простые средства командной строки и методы, а также более сложные средства. Сначала мы рассмотрим простые методы. Но если у вас возникла проблема с производительностью прямо сейчас, следует перейти к расширенным методам и опробовать пример плана действий по устранению неполадок с производительностью.

Простые методы

Цель этих простых методов — научиться принимать, понимать и правильно хранить простые базовые показатели производительности с течением времени, чтобы вы были проинформированы о производительности Office 365. Вот простая схема для простого, как вы видели ранее:

Примечание.

TraceTCP включен в этот снимок экрана, так как это полезное средство для отображения (в миллисекундах), сколько времени занимает обработка запроса и сколько сетевых прыжков или подключений от одного компьютера к другому требуется запросу для достижения места назначения. TraceTCP также может предоставлять имена серверов, используемых во время прыжков, что может быть полезно для средства устранения неполадок Microsoft Office 365 в службе поддержки. > Команды TraceTCP могут быть очень простыми, например: >tracetcp.exe outlook.office365.com:443> Не забудьте включить номер порта в команду! >TraceTCP — это бесплатная загрузка, но она использует Wincap. Wincap — это средство, которое также используется и устанавливается Netmon. Мы также используем Netmon в разделе расширенных методов.

Если у вас несколько офисов, вам также потребуется хранить набор данных от клиента в каждом из этих расположений. Этот тест измеряет задержку, которая в данном случае представляет собой числовое значение, описывающее время между отправкой клиентом запроса к Office 365 и Office 365 ответа на запрос. Тестирование происходит внутри вашего домена на клиентском компьютере и измеряет круговой путь из вашей сети, через точку исходящего трафика, через Интернет до Office 365 и обратно.

Существует несколько способов справиться с точкой исходящего трафика, в данном случае с прокси-сервером. Можно выполнить трассировку от 1 до 2, а затем от 2 до 3, а затем добавить числа в миллисекундах, чтобы получить окончательный итог на границе сети. Кроме того, можно настроить подключение так, чтобы обойти прокси-сервер для Office 365 адресов. В более крупной сети с брандмауэром, обратным прокси-сервером или какой-либо комбинацией этих двух компонентов может потребоваться сделать исключения на прокси-сервере, которые позволят трафику передаваться по большому количеству URL-адресов. Список конечных точек, используемых Office 365, см. в разделе Office 365 URL-адреса и диапазоны IP-адресов. Если у вас есть прокси-сервер для проверки подлинности, начните с тестирования исключений для следующих компонентов:

• Порты 80 и 443

• TCP и HTTPs

• Connections, которые являются исходящими для любого из этих URL-адресов:

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

Всем пользователям необходимо разрешить доступ к этим адресам без вмешательства прокси-сервера или проверки подлинности. В меньшей сети их следует добавить в список обхода прокси-сервера в веб-браузере.

Чтобы добавить их в список обхода прокси-сервера в Internet Обозреватель, перейдите в раздел Сервис>параметры> браузера Connections>лс>дополнительно. На вкладке "Дополнительно" также можно найти прокси-сервер и порт прокси-сервера. Для доступа к кнопке Дополнительно может потребоваться установить флажок Использовать прокси-сервер для локальной сети. Убедитесь, что установлен флажок Обход прокси-сервера для локальных адресов . После нажатия кнопки Дополнительно вы увидите текстовое поле, в котором можно ввести исключения. Разделите перечисленные выше URL-адреса с подстановочными знаками с запятой, например:

*.microsoftonline.com; *.sharepoint.com

После обхода прокси-сервера вы сможете использовать ping или PsPing непосредственно по URL-адресу Office 365. Следующим шагом будет проверка проверки подлинности outlook.office365.com. Кроме того, если вы используете PsPing или другое средство, позволяющее указать номер порта команде PsPing для portal.microsoftonline.com:443 , чтобы увидеть среднее время кругового пути в миллисекундах.

Время кругового пути или RTT — это число, которое измеряет время отправки HTTP-запроса на сервер, например outlook.office365.com, и возвращает ответ, который подтверждает, что сервер знает, что это было выполнено. Иногда это сокращение будет называться RTT. Это должно быть относительно короткое время.

Для выполнения этого теста необходимо использовать PSPing или другое средство, которое не использует пакеты ICMP, заблокированные Office 365.

Использование PsPing для получения общего времени кругового пути в миллисекундах непосредственно из URL-адреса Office 365

1. Запустите командную строку с повышенными привилегиями, выполнив следующие действия:

2. Нажмите Пуск.

3. В поле Пуск Поиск введите cmd и нажмите клавиши CTRL+SHIFT+ВВОД.

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

5. Перейдите в папку, в которой установлено средство (в данном случае PsPing), и проверьте следующие OFFICE 365 URL-адреса:

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• outlook.office365.com:443 psping

• www.yammer.com:443 psping

  

Укажите номер порта 443. Помните, что Office 365 работает в зашифрованном канале. Если вы используете PsPing без номера порта, запрос завершится ошибкой. После проверки доступа к короткому списку найдите среднее время в миллисекундах (мс). Это то, что вы хотите записать!

Если вы не знакомы с обходом прокси-сервера и предпочитаете выполнять пошаговые действия, необходимо сначала узнать имя прокси-сервера. В разделе Интернет-Обозреватель перейдите в раздел Сервис>Параметры> браузера Connections>лс дополнительно>. На вкладке Дополнительно отобразится список прокси-сервера. Проверка связи с прокси-сервером в командной строке, выполнив следующую задачу:

Проверка проверки связь с прокси-сервером и получение значения кругового пути в миллисекундах для этапа 1–2

1. Запустите командную строку с повышенными привилегиями, выполнив следующие действия:

2. Нажмите Пуск.

3. В поле Пуск Поиск введите cmd и нажмите клавиши CTRL+SHIFT+ВВОД.

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

5. Введите ping <имя прокси-сервера, используемого браузером, или IP-адрес прокси-сервера> , а затем нажмите клавишу ВВОД. Если у вас установлен PsPing или какое-либо другое средство, вы можете использовать это средство.

   Команда может выглядеть следующим образом:

• ping ourproxy.ourdomain.industry.business.com

• ping 155.55.121.55

• ping ourproxy

• ourproxy.ourdomain.industry.business.com:80 psping

• psping 155.55.121.55:80

• psping ourproxy:80

3. Когда трассировка прекратит отправку тестовых пакетов, вы получите небольшую сводку, которая содержит среднее значение в миллисекундах. Создайте снимок экрана запроса и сохраните его с помощью соглашения об именовании. На этом этапе также может помочь заполнить схему значением .

Может быть, вы выполнили трассировку рано утром, и ваш клиент может быстро добраться до прокси-сервера (или любого исходящего сервера, выходя в Интернет). В этом случае ваши номера могут выглядеть следующим образом:

Если клиентский компьютер является одним из немногих с доступом к прокси-серверу (или серверу исходящего трафика), вы можете запустить следующий этап теста, удаленно подключившись к нему, запустив командную строку psPing по URL-адресу Office 365. Если у вас нет доступа к компьютеру, вы можете обратиться к сетевым ресурсам за помощью в следующем этапе и получить точные номера таким образом. Если это невозможно, возьмем PsPing для указанного URL-адреса Office 365 и сравните его со временем PsPing или Ping с прокси-сервером.

Например, если у вас есть 51,84 миллисекунда от клиента до URL-адреса Office 365 и 2,8 миллисекунда от клиента до прокси-сервера (или точки исходящего трафика), то от исходящего трафика до Office 365 у вас будет 49,04 миллисекунда. Аналогичным образом, если у вас есть psPing 12,25 миллисекунда от клиента до прокси-сервера в течение дня и 62,01 миллисекунда от клиента до URL-адреса Office 365, среднее значение для исходящего прокси-сервера в URL-адрес Office 365 будет равно 49,76 миллисекундам.

Что касается устранения неполадок, вы можете найти что-то интересное только из сохранения этих базовых показателей. Например, если вы обнаружите, что задержка от прокси-сервера или точки исходящего трафика до URL-адреса Office 365 обычно имеет от 40 миллисекунд до 59 миллисекунд, и иметь клиент для прокси-сервера или точки исходящего трафика задержки от 3 миллисекунда до 7 миллисекунда (в зависимости от объема сетевого трафика, который вы видите в течение этого времени суток), то вы, несомненно, знаете, что-то проблематично, если последние три клиента прокси-сервера или исходящие базовые показатели показывают задержка в 45 миллисекундах.

Расширенные методы

Если вы действительно хотите узнать, что происходит с вашими интернет-запросами на Office 365, необходимо ознакомиться с трассировками сети. Не имеет значения, какие средства вы предпочитаете для этих трассировок, HTTPWatch, Netmon, Анализатор сообщений, Wireshark, Fiddler, средство панели мониторинга разработчика или любое другое, если это средство может захватывать и фильтровать сетевой трафик. В этом разделе вы увидите, что полезно запустить несколько из этих средств, чтобы получить более полное представление о проблеме. При тестировании некоторые из этих средств также действуют как прокси-серверы. Средства, используемые в дополнительной статье План устранения неполадок с производительностью для Office 365, включают Netmon 3.4, HTTPWatch или WireShark.

Использование базовых показателей производительности является простой частью этого метода, и многие шаги выполняются так же, как при устранении проблем с производительностью. Более сложные методы создания базовых показателей производительности требуют получения и хранения трассировок сети. В большинстве примеров в этой статье используется SharePoint, но следует разработать список распространенных действий в Office 365 службах, на которые вы подписаны на тестирование и запись. Ниже приведен базовый пример.

• Базовый список для SPO — ** Шаг 1. ** Просмотрите домашнюю страницу веб-сайта SPO и выполните трассировку сети. Сохраните трассировку.

• Базовый список для SPO. Шаг 2. Поиск термина (например, название вашей компании) через корпоративный Поиск и выполнить трассировку сети. Сохраните трассировку.

• Базовый список для SPO. Шаг 3. Отправка большого файла в библиотеку документов SharePoint и выполнение трассировки сети. Сохраните трассировку.

• Базовый список SPO. Шаг 4. Просмотрите домашнюю страницу веб-сайта OneDrive и выполните трассировку сети. Сохраните трассировку.

Этот список должен содержать наиболее важные распространенные действия, выполняемые пользователями в отношении SharePoint. Обратите внимание, что на последнем шаге для трассировки в OneDrive выполняется сравнение загрузки домашней страницы SharePoint (которая часто настраивается компаниями) и домашней страницы OneDrive, которая редко настраивается. Это базовый тест, когда речь идет о медленной загрузке сайта SharePoint. Вы можете создать запись об этом различии в тестировании.

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

Чтобы решить проблему с производительностью, прямо сейчас необходимо выполнить трассировку во время возникновения проблемы с производительностью. Необходимо иметь соответствующие средства для сбора журналов, а также план действий, то есть список действий по устранению неполадок, которые необходимо предпринять для сбора наилучших сведений. Первое, что нужно сделать, — запишите дату и время теста, чтобы файлы можно было сохранить в папке, отражающей время. Затем сузите до самих шагов проблемы. Это точные шаги, которые вы будете использовать для тестирования. Не забывайте об основных принципах: если проблема связана только с Outlook, убедитесь, что проблема возникает только в одной Office 365 службе. Сузив область этой проблемы, вы сможете сосредоточиться на том, что можно решить.

См. также

Управление конечными точками Office 365