Настройка производительности 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 Online, например, щелкните "Описание службы SharePoint Online" и найдите раздел "Ограничения SharePoint Online".

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

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

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

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

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

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

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

Изображение панели мониторинга работоспособности Office 365, где объясняется, Exchange Online восстановлена служба и почему.

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

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

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

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

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

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

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

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

  • Переход с папки "Входящие" на "Календарь" был тем, что я не заметил, а теперь это кофе-перерыв. Можно ли сделать так, как было?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовый сетевой рисунок, показывающий клиент, прокси-сервер и Office 365 облако.

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

Базовая сеть с клиентами, прокси-серверами и облаком и инструментами предлагает PSPing, TraceTCP и трассировку сети.

Эти параметры перечислены как Простые и расширенные из-за опыта, необходимого для поиска данных о производительности. Трассировка сети займет много времени по сравнению с выполнением таких программ командной строки, как 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><what's happening in the test> но для начала рекомендуется использовать формат. Это поможет вам в дальнейшем при попытке устранить неполадки. Позже вы сможете сказать: "Я выполнил две трассировки 8 февраля, одна показывает хорошую производительность, а одна — неправильная, поэтому мы можем сравнить их". Это полезно для устранения неполадок.

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовая сеть с клиентами, прокси-серверами и облаком и инструментами предлагает PSPing, TraceTCP и трассировку сети.

Примечание

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 и HTTP

  • Подключения, исходящие по любому из этих URL-адресов:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

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

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

*.microsoftonline.com; *.sharepoint.com

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

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

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

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

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

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

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

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

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

  • psping admin.microsoft.com:443

  • psping microsoft-my.sharepoint.com:443

  • psping outlook.office365.com:443

  • psping www.yammer.com:443

    Команда PSPing будет microsoft-my.sharepoint.com порт 443.

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

Рисунок, на котором показана схема передачи psPing между клиентом и прокси-сервером со временем кругового пути 2,8 миллисекунда.

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

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

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

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

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

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

  5. Введите проверку связи <the name of the proxy server your browser uses, or the IP address of the proxy server> и нажмите клавишу ВВОД. Если у вас установлен PsPing или другое средство, вы можете использовать это средство.

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

  • проверка связи ourproxy.ourdomain.industry.business.com

  • ping 155.55.121.55

  • ping ourproxy

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

  • psping 155.55.121.55:80

  • psping ourproxy:80

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

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

Рисунок, на котором показано время кругового пути от клиента до прокси-сервера в 2,8 миллисекунда.

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

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

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

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

Дополнительные методы

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

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

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

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

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

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

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

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

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

См. также

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