使用基线和性能历史记录优化 Office 365 性能

  • 项目

有一些简单的方法可以检查Office 365与企业之间的连接性能，以便建立连接的大致基线。 了解客户端计算机连接的性能历史记录有助于及早检测新出现的问题、识别和预测问题。

如果你不习惯处理性能问题，本文旨在帮助你考虑一些常见问题。 如何知道你看到的问题是性能问题，而不是Office 365服务事件？ 如何规划长期良好的性能？ 如何关注性能？ 如果你的团队或客户端在使用Office 365时看到性能缓慢，并且你想知道其中任何一个问题，请继续阅读。

重要

客户端与Office 365之间现在有性能问题？ 按照Office 365的性能故障排除计划中所述的步骤进行操作。

有关性能Office 365应了解的内容

Office 365位于由自动化和真实人员监视的高容量专用 Microsoft 网络中。 维护Office 365云的一部分是尽可能优化和简化性能。 由于Office 365云的客户端必须通过 Internet 进行连接，因此，我们一直在努力优化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的用户的呼叫。 通话将在中午左右结束。

此列表可能听起来很熟悉：也许太熟悉了 一旦你意识到这是一个性能问题，问题就变成了“你接下来该怎么办？”本文的其余部分可帮助你准确确定这一点。

如何定义和测试性能问题

性能问题经常随着时间的推移而出现，因此定义实际问题可能具有挑战性。 创建一个良好的问题语句，并了解问题上下文，然后需要重复测试步骤。 下面是未提供足够信息的问题语句的一些示例：

  • 从“收件箱”切换到“日历”过去是我没有注意到的，现在，这是一个茶歇。 你能让它像以前那样行事吗？

  • 将文件上传到 SharePoint Online 需要永远。 为什么下午很慢，但其他任何时间，它都快？ 难道不是快吗？

上述问题陈述带来了几个巨大的挑战。 具体而言，需要处理的模棱两可太多。 例如：

  • 目前还不清楚在“收件箱”和“日历”之间如何切换以在笔记本电脑上进行操作。

  • 当用户说“不能只是快”时，什么是“快速”？

  • “永久”有多长？ 是几秒钟吗？ 还是多分钟？ 或者用户能否吃午饭，操作会在他们回来后 10 分钟完成？

管理员和疑难解答无法从此类常规语句中了解问题 的详细信息 。 例如，他们不知道问题何时开始发生。 疑难解答可能不知道用户在家工作，并且仅在其家庭网络上看到切换速度缓慢。 或者用户在本地客户端上运行其他 RAM 密集型应用程序。 管理员可能不知道用户运行的是较旧的操作系统，或者尚未运行最近的更新。

当用户报告性能问题时，需要收集大量信息。 获取和记录信息称为界定问题范围。 下面是可用于收集有关性能问题的信息的基本范围列表。 此列表并不详尽，但它是一个开始的地方：

  • 问题发生在哪一天，大约在白天或晚上的什么时间？

  • 你使用的是哪种类型的客户端计算机，它如何连接到业务网络 (VPN、有线、无线) ？

  • 你是远程工作还是办公室里？

  • 你是否在另一台计算机上尝试了相同的操作并看到相同的行为？

  • 逐步完成带来麻烦的步骤，以便你可以编写你采取的操作。

  • 性能以秒或分钟为单位有多慢？

  • 你位于世界上的哪个位置？

其中一些问题比其他问题更为明显。 大多数人都会了解疑难解答需要确切的步骤来重现问题。 毕竟，你如何记录错误，以及你如何测试问题是否已修复？ 不太明显的是“你看到了问题的日期和时间？”和“你位于世界上的哪个位置？”，以及可以协同使用的信息。 根据用户工作的时间，几个小时的时差可能意味着公司网络的某些部分已在进行维护。 例如，贵公司有一个混合实现，例如混合 SharePoint 搜索，它可以查询 SharePoint Online 和本地 SharePoint Server 2013 实例中的搜索索引，更新可能正在本地场中进行。 如果公司全部在云中，系统维护可能包括添加或删除网络硬件、推出公司范围的更新，或者对 DNS 或其他核心基础结构进行更改。

当你排查性能问题时，它有点像犯罪现场，你需要精确和观察才能从证据中得出任何结论。 为此，必须通过收集证据来获得良好的问题陈述。 它应包括计算机的上下文、用户的上下文、问题开始时间以及暴露性能问题的确切步骤。 这个问题陈述应该是笔记中最顶层的页面。 在完成解决方法后，再次演练问题陈述，你将采取步骤来测试和证明你采取的操作是否解决了问题。 这对于了解你的工作何时完成至关重要。

你知道性能在良好时的表现如何吗？

如果你运气不好，没人知道。 没有人有数字。 这意味着没有人能回答以下简单问题：“在Office 365中打开收件箱需要花费多少秒？”或“高管们召开 Lync Online 会议时需要多长时间？”，这是许多公司的常见方案。

此处缺少的是性能基线？

基线提供了性能上下文。 根据公司的需求，你应偶尔使用基线。 如果你是一家较大的公司，运营团队可能已经为本地环境创建基线。 例如，如果在当月的第一个星期一修补所有 Exchange 服务器，并在第三个星期一修补所有 SharePoint 服务器，则运营团队可能有一个任务列表和方案，它会在修补后运行，以证明关键功能可正常运行。 例如，打开“收件箱”，单击“发送/接收”，并确保文件夹更新，或者在 SharePoint 中浏览网站的主页，进入企业搜索页面，然后执行返回结果的搜索。

如果应用程序处于Office 365，则可以测量一些最基本的基线 (时间（以毫秒为单位），) 从网络中的客户端计算机到出口点，或者离开网络并转到Office 365的点。 下面是一些可以调查和记录的有用基线：

  • 确定客户端计算机与出口点之间的设备，例如代理服务器。

    • 必须了解设备，以便获得上下文 (IP 地址、设备类型等) 出现的性能问题。

    • 代理服务器是常见的出口点，因此你可以检查 Web 浏览器，查看它设置为使用的代理服务器（如果有）。

    • 有一些第三方工具可以发现和映射你的网络，但了解设备的最安全方法是询问网络团队成员。

  • 确定 Internet 服务提供商 (ISP) ，记下他们的联系信息，并询问有多少线路有多少带宽。

  • 在公司内部，确定客户端和出口点之间的设备资源，或确定紧急联系人以讨论网络问题。

下面是使用工具进行简单测试可以计算的一些基线：

  • 从客户端计算机到出口点的时间（以毫秒为单位）

  • 从出口点到Office 365的时间（以毫秒为单位）

  • 浏览时解析Office 365 URL 的服务器所在位置

  • ISP 的 DNS 解析速度（以毫秒为单位），数据包到达 (网络抖动) 、上传和下载时间（以毫秒为单位）

如果你不熟悉如何执行这些步骤，我们将在本文中详细介绍。

什么是基线？

当它变坏时，你会知道影响，但如果不知道你的历史性能数据，则不可能有一个上下文来说明它可能变得多么糟糕，以及何时出现。 因此，如果没有基线，就缺少解决谜题的关键线索：拼图框上的图片。 在性能故障排除中，需要一个 比较点。 简单的性能基线并不难采用。 运营团队的任务是按计划执行这些操作。 例如，假设连接如下所示：

显示客户端、代理和Office 365云的基本网络图形。

这意味着你已与网络团队进行了检查，发现你通过代理服务器离开公司以使用 Internet，并且代理将处理客户端计算机发送到云的所有请求。 在这种情况下，应绘制一个简化版本的连接，其中列出了所有干预设备。 现在，插入可用于测试客户端、出口点 (将网络用于 Internet) 和Office 365云之间的性能的工具。

包含客户端、代理和云的基本网络以及工具建议 PSPing、TraceTCP 和网络跟踪。

由于需要大量的专业知识才能找到性能数据，因此这些选项被列为 “简单 ”和“ 高级 ”。 与运行 PsPing 和 TraceTCP 等命令行工具相比，网络跟踪将花费大量时间。 之所以选择这两个命令行工具，是因为它们不使用 ICMP 数据包（Office 365会阻止这些数据包），并且它们会提供离开客户端计算机或代理服务器所花费的时间（以毫秒为单位）， (如果你有访问) 并到达Office 365。 从一台计算机到另一台计算机的每一个跃点最终都会有一个时间值，这非常适合基线！ 同样重要的是，这些命令行工具允许你向命令添加端口号，这很有用，因为Office 365通过端口 443 进行通信，这是安全套接字层和传输层安全性 (SSL 和 TLS) 使用的端口。 但是，其他第三方工具可能更适合你的情况。 Microsoft 不支持所有这些工具，因此，如果出于某种原因无法使 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><在测试>中发生的情况是一个很好的起点。 在以后尝试排查问题时，勤于此会有很大的帮助。 稍后，你将能够说“我在2月8日拍摄了两个痕迹，一个表现出良好的表现，一个表现出不好，所以我们可以比较它们”。 这有助于进行故障排除。

需要有条理地保留历史基线。 在此示例中，简单方法生成了三个命令行输出，结果以屏幕截图的形式收集，但你可能具有网络捕获文件。 使用最适合你的方法。 存储历史基线，并在你注意到联机服务行为发生更改的点引用它们。

为什么在试点期间收集性能数据？

在Office 365服务试点期间，没有比开始创建基线更好的时间了。 你的办公室可能有数千个用户、数十万个用户，或者可能有五个用户，但即使只有少数用户，你也可以执行测试来衡量性能波动。 对于一家大公司，可以向外投影数千个用户试点Office 365的代表性示例，以便在问题发生之前知道可能出现的问题。

对于一家小公司，如果加入意味着所有用户同时访问服务，并且没有试点，请保持性能措施，以便向可能必须对运行不佳的操作进行故障排除的任何人显示数据。 例如，如果你注意到突然间，你可以在建筑物中四处走动，以将中等大小的图形上传到该图形的快速发生位置。

如何收集基线

对于所有故障排除计划，至少需要识别以下事项：

  • 你使用的客户端计算机 (计算机或设备的类型、IP 地址以及导致问题的操作)

  • 客户端计算机所在的位置 (例如，无论此用户位于网络 VPN 上、远程工作还是在公司 Intranet 上)

  • 客户端计算机从网络使用的出口点 (流量从 ISP 或 Internet)

可以从网络管理员处了解网络布局。 如果你使用的是小型网络，请查看连接到 Internet 的设备，如果对布局有疑问，请拨打 ISP。 创建最终布局的图形以供参考。

本部分分为简单的命令行工具和方法，以及更高级的工具选项。 我们将首先介绍简单的方法。 但是，如果现在遇到性能问题，则应跳转到高级方法，并试用示例性能故障排除操作计划。

简单方法

这些简单方法的目的是学习如何随着时间的推移采用、理解和正确存储简单的性能基线，以便了解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响应请求之间的时间。 测试起源于客户端计算机上的域内，旨在测量从网络内部、通过出口点、通过 Internet 到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

需要允许所有用户在没有任何代理干扰或身份验证的情况下访问这些地址。 在较小的网络上，应将这些内容添加到 Web 浏览器中的代理绕过列表。

若要将这些内容添加到 Internet Explorer 中的代理绕过列表，请转到“工具>”“Internet 选项”“>连接 >LAN 设置>高级”。 还可以在“高级”选项卡中找到代理服务器和代理服务器端口。 可能需要单击“ 使用 LAN 的代理服务器”复选框才能访问“ 高级 ”按钮。 需要确保选中 “绕过本地地址的代理服务器 ”。 单击“ 高级”后，你将看到一个文本框，可在其中输入异常。 使用分号分隔上面列出的通配符 URL，例如：

*.microsoftonline.com;*.sharepoint.com

绕过代理后，你应该能够直接在Office 365 URL 上使用 ping 或 PsPing。 下一步是测试 ping outlook.office365.com。 或者，如果你使用的是 PsPing 或其他允许向命令提供端口号的工具，则 PsPing 针对 portal.microsoftonline.com:443 查看平均往返时间（以毫秒为单位）。

往返时间（即 RTT）是一个数字值，用于度量将 HTTP 请求发送到服务器（如 outlook.office365.com）所需的时间，并返回一个响应，确认服务器知道你这样做了。 有时会看到此缩写为 RTT。 这应该相对较短的时间。

必须使用 PSPing 或其他不使用被Office 365阻止的 ICMP 数据包的工具才能执行此测试。

如何使用 PsPing 直接从Office 365 URL 获取总体往返时间（以毫秒为单位）

  1. 通过完成以下步骤，运行提升的命令提示符：

  2. 单击“开始”。

  3. 在 “开始搜索 ”框中，键入 cmd，然后按 Ctrl+Shift+ENTER。

  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

    转到 microsoft-my.sharepoint.com 端口 443 的 PSPing 命令。

请确保包含端口号 443。 请记住，Office 365适用于加密通道。 如果 PsPing 没有端口号，请求将失败。 对简短列表执行 ping 操作后，查找平均时间（以毫秒为单位 (毫秒) ）。 这就是你想要录制的内容！

显示往返时间为 2.8 毫秒的客户端到代理 PSPing 的插图。

如果不熟悉代理旁路，并且希望分步执行操作，则需要首先找出代理服务器的名称。 在 Internet Explorer 中，转到“工具>”“Internet 选项”“>连接 >LAN 设置>高级”。 “ 高级 ”选项卡是列出代理服务器的位置。 通过完成以下任务，在命令提示符下 Ping 该代理服务器：

ping 代理服务器并获取第 1 到 2 阶段的往返值（以毫秒为单位）

  1. 通过完成以下步骤，运行提升的命令提示符：

  2. 单击“开始”。

  3. 在 “开始搜索 ”框中，键入 cmd，然后按 Ctrl+Shift+ENTER。

  4. 如果出现“用户帐户控制”对话框，请确认所显示的是您想要执行的操作，然后单击“继续”。

  5. 键入 ping <浏览器使用的代理服务器的名称或代理服务器> 的 IP 地址，然后按 Enter。 如果已安装 PsPing 或其他工具，可以选择改用该工具。

    命令可能类似于以下任何示例：

  • ping 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. 当跟踪停止发送测试数据包时，你将收到一个小摘要，其中列出了平均值（以毫秒为单位），这是你想要的值。 获取提示的屏幕截图，并使用命名约定保存它。 此时，使用 值填充关系图也可能会有所帮助。

也许你在清晨就进行了跟踪，客户端可以快速访问代理 (或任何出口服务器退出 Internet) 。 在这种情况下，你的数字可能如下所示：

显示从客户端到代理的往返时间为 2.8 毫秒的图形。

如果你的客户端计算机是少数有权访问代理 (或出口) 服务器的用户之一，则可以通过远程连接到该计算机来运行测试的下一步，从该计算机运行 PsPing 到Office 365 URL 的命令提示符。 如果无法访问该计算机，可以联系网络资源，以获取下一个回合的帮助，并获取确切的数字。 如果这是不可能的，请对有问题的Office 365 URL 使用 PsPing，并将其与针对代理服务器的 PsPing 或 Ping 时间进行比较。

例如，如果从客户端到Office 365 URL 有 51.84 毫秒，并且从客户端到代理 (或出口点) 有 2.8 毫秒，则从出口到Office 365有 49.04 毫秒。 同样，如果在当天的高度，从客户端到代理的 PsPing 为 12.25 毫秒，从客户端到Office 365 URL 的 PsPing 为 62.01 毫秒，则代理流出到Office 365 URL 的平均值为 49.76 毫秒。

其他图形显示从客户端到代理的 ping（以毫秒为单位），在客户端到Office 365以便可以减去值。

在故障排除方面，你可能会发现一些有趣的内容，只是保留这些基线。 例如，如果你发现从代理或出口点到Office 365 URL 的延迟通常约为 40 毫秒到 59 毫秒，并且客户端到代理或出口点的延迟大约为 3 毫秒到 7 毫秒 (具体取决于你在一天中的这段时间内看到的网络流量) 那么如果最后三个客户端到代理或出口，则肯定知道有些问题基线显示 45 毫秒的延迟。

高级方法

如果真的想要了解Office 365的 Internet 请求发生了什么情况，则需要熟悉网络跟踪。 对于这些跟踪，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 for Business，在 SharePoint Online 主页的负载 (（通常由) 公司自定义）和OneDrive for Business主页（很少自定义）之间进行比较。 对于加载缓慢的 SharePoint Online 网站，这是一个基本测试。 可以在测试中生成此差异的记录。

如果遇到性能问题，则许多步骤与创建基线时的步骤相同。 网络跟踪变得至关重要，因此接下来我们将处理 如何 获取重要跟踪。

若要解决性能问题， 现在需要在遇到性能问题时进行跟踪。 你需要有适当的工具可用于收集日志，并且需要一个行动计划，即要采取的故障排除操作列表，以收集最佳信息。 首先要做的是记录测试的日期和时间，以便文件可以保存在反映时间的文件夹中。 接下来，请缩小到问题步骤本身。 以下是用于测试的确切步骤。 不要忘记基础知识：如果问题仅与 Outlook 有关，请确保将问题行为记录在一个Office 365服务中。 缩小此问题的范围将帮助你专注于可以解决的问题。

另请参阅

管理 Office 365 终结点