使用基线和性能历史记录优化 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管理员应检查当前运行状况，然后经常查看详细信息和历史记录，以随时了解系统维护情况。 “ 当前运行状况 ”仪表板是为你更新服务的更改和问题而创建的。 写入运行状况历史记录（管理员为管理员）的笔记和说明可帮助你进行评估，并随时发布有关正在进行的工作的说明和说明。
性能问题不是服务事件，即使事件可能会导致性能降低。 性能问题如下所示：
无论管理中心 当前运行状况 为服务报告什么，都会出现性能问题。
用于流的行为需要很长时间才能完成或永不完成。
也可以复制问题，或者知道如果执行了一系列正确的步骤，问题就会发生。
如果问题是间歇性的，则仍有一种模式。 例如，你知道，到上午 10：00，你将收到用户打来的电话，这些用户不能始终访问Office 365。 呼叫将在中午左右结束。
此列表听起来可能很熟悉;也许太熟悉了 一旦你意识到这是一个性能问题，问题就变成了“你下一步该怎么办？”本文的其余部分可帮助你准确确定这一点。
如何定义和测试性能问题
性能问题通常会随时间推移而出现，因此定义实际问题可能很困难。 创建一个好的问题语句，并了解问题上下文，然后需要重复测试步骤。 下面是一些问题语句示例，这些示例未提供足够的信息：
从收件箱切换到日历过去是我没有注意到的东西， 现在它是一个咖啡休息。 你能让它像以前那样吗？
将文件上传到 SharePoint Online 需要很长时间。 为什么下午速度很慢，但其他任何时候，速度都很快？ 不能只是快吗？
上述问题陈述带来了一些巨大的挑战。 具体而言，有太多的歧义无法处理。 例如：
目前还不清楚如何在收件箱和日历之间切换用于在笔记本电脑上执行操作。
当用户说“不能只是快”时，什么是“快”？
“永远”有多长？ 是几秒钟吗？ 还是几分钟？ 还是用户可以吃午饭，操作会在他们回来后 10 分钟完成？
管理员和疑难解答人员无法从诸如此类的常规语句中了解问题的 详细信息 。 例如，他们不知道问题何时开始发生。 疑难解答可能不知道用户在家工作，并且只在家庭网络上看到切换速度缓慢。 或者用户在本地客户端上运行其他 RAM 密集型应用程序。 管理员可能不知道用户正在运行较旧的操作系统，或者没有运行最近的更新。
当用户报告性能问题时，需要收集大量信息。 获取和记录信息称为界定问题的范围。 下面是一个基本的范围列表，可用于收集有关性能问题的信息。 此列表并非详尽无遗，但它是一个开始的地方：
问题发生在哪个日期，以及白天或晚上的什么时间？
你使用的是哪种客户端计算机，它如何连接到业务网络 (VPN、有线、无线) ？
你是远程工作还是在办公室工作？
是否在另一台计算机上尝试了相同的操作，并看到了相同的行为？
演练给你带来麻烦的步骤，以便你可以编写你采取的操作。
性能有多慢（秒或分钟）？
你在世界上在哪里？
其中一些问题比其他问题更明显。 大多数人都会了解疑难解答需要准确的步骤来重现问题。 毕竟，你还能如何记录错误，以及如何测试问题是否已修复？ 不太明显的是“你看到了什么日期和时间？”和“你在世界上在哪里？ 根据用户的工作时间，几个小时的时差可能意味着公司网络的某些部分已经在进行维护。 例如，你的公司有一个混合实现，例如混合 SharePoint 搜索，它可以在 SharePoint Online 和本地 SharePoint Server 2013 实例中查询搜索索引，更新可能正在本地场中进行。 如果你的公司都位于云中，系统维护可能包括添加或删除网络硬件、推出公司范围内的更新，或者对 DNS 或其他核心基础结构进行更改。
当你对性能问题进行故障排除时，它有点像犯罪现场，你需要精确观察，以便从证据中得出任何结论。 为此，你必须通过收集证据来获得良好的问题陈述。 它应包括计算机的上下文、用户的上下文、问题开始时以及暴露性能问题的确切步骤。 此问题语句应为笔记中最顶层的页面并保留。 通过在处理解决方法后再次浏览问题语句，你将执行以下步骤来测试并证明你采取的操作是否已解决问题。 这对于了解工作何时完成至关重要。
你知道在性能好的时候性能如何吗？
如果你倒霉，没人知道 没有人有号码。 这意味着没有人能回答简单的问题：“关于在Office 365中提出收件箱需要多少秒？
此处缺少的性能基线是什么？
基线提供性能上下文。 应根据公司的需求，偶尔经常采用基线。 如果你是一家较大的公司，则运营团队可能已根据本地环境采用基线。 例如，如果在每月的第一个星期一修补所有 Exchange 服务器，在第三个星期一修补所有 SharePoint 服务器，则运营团队可能有一系列任务和方案，这些任务和方案会在修补后运行，以证明关键函数可正常运行。 例如，打开收件箱，单击“发送/接收”，并确保文件夹更新，或者在 SharePoint 中浏览网站主页，进入企业搜索页，并执行返回结果的搜索。
如果应用程序处于Office 365中，可以使用一些最基本的基线来度量 (从网络中的客户端计算机) 到出口点或离开网络并外出Office 365的时间（以毫秒为单位）。 下面是一些有用的基线，你可以调查和记录：
标识客户端计算机和出口点之间的设备，例如代理服务器。
你必须了解设备，以便你对出现的性能问题具有上下文 (IP 地址、设备类型等) 。
代理服务器是常见的出口点，因此可以检查 Web 浏览器，查看设置为要使用的代理服务器（如果有）。
有第三方工具可以发现和映射网络，但了解设备的最安全方法是询问网络团队的成员。
确定你的 Internet 服务提供商 (ISP) ，记下其联系信息，并询问有多少线路的带宽。
在公司内部，确定客户端与出口点之间设备的资源，或确定紧急联系人，以便与之讨论网络问题。
下面是一些使用工具进行简单测试可以计算的基线：
从客户端计算机到出口点的时间（以毫秒为单位）
从出口点到Office 365的时间（以毫秒为单位）
在浏览时解析Office 365 URL 的服务器世界中的位置
ISP 的 DNS 解析速度（以毫秒为单位）、数据包到达时不一致 (网络抖动) 、上传和下载时间（以毫秒为单位）
如果不熟悉如何执行这些步骤，我们将在本文中详细介绍。
什么是基线？
当其变坏时，你将知道其影响，但如果不知道历史性能数据，则无法在上下文中了解其可能变得多么糟糕以及何时变坏。 因此，如果没有基线，你就缺少解决拼图的关键线索：拼图框上的图片。 在性能故障排除中，需要 一个比较点。 不难采用简单的性能基线。 运营团队可以按计划执行这些任务。 例如，假设连接如下所示：
这意味着你已与网络团队核实，发现你通过代理服务器将公司留在 Internet，并且代理处理客户端计算机发送到云的所有请求。 在这种情况下，应绘制一个简化的连接版本，其中列出了所有中间设备。 现在，插入可用于测试客户端、出口点 (将网络留给 Internet) 和Office 365云之间的性能的工具。
这些选项被列为 简单 和 高级 选项，因为需要大量的专业知识才能查找性能数据。 与运行 PsPing 和 TraceTCP 等命令行工具相比，网络跟踪需要花费大量时间。 之所以选择这两个命令行工具，是因为它们不使用 ICMP 数据包，而 ICMP 数据包会被Office 365阻止，并且它们提供离开客户端计算机所需的时间（毫秒）或代理服务器 (（如果你有权访问) 并到达Office 365）。 从一台计算机到另一台计算机的每一个跃点最终都会有一个时间值，这非常适合基线！ 同样重要的是，这些命令行工具允许你将端口号添加到命令中，这非常有用，因为Office 365通过端口 443 进行通信，端口 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性能。 下面是简单关系图，如你之前所见：
注意
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 或其他可为命令提供端口号的工具，请对 portal.microsoftonline.com:443 执行 PsPing 操作，以查看平均往返时间（毫秒）。
往返时间（即 RTT）是一个数字值，用于度量向 outlook.office365.com 等服务器发送 HTTP 请求并返回一个确认服务器知道已执行该操作的响应所需的时间。 有时会看到此缩写为 RTT。 这应该是相对较短的时间。
若要执行此测试，必须使用 PSPing 或其他不使用被Office 365阻止的 ICMP 数据包的工具。
如何使用 PsPing 直接从Office 365 URL 获取总体往返时间（以毫秒为单位）
完成以下步骤，运行提升的命令提示符：
单击“开始”。
在 “开始搜索 ”框中键入 cmd，然后按 CTRL+SHIFT+ENTER。
如果出现“用户帐户控制”对话框，请确认所显示的是您想要执行的操作，然后单击“继续”。
导航到在本例中安装工具 (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
请务必包含端口号 443。 请记住，Office 365适用于加密通道。 如果没有端口号，则请求将失败。 打平短列表后，请查找 ms) (的平均时间（毫秒）。 这就是你想要录制的内容！
如果你不熟悉代理旁路，并且喜欢逐步执行操作，则需要先找出代理服务器的名称。 在 Internet Explorer 中，转到 “工具>Internet 选项>连接>LAN 设置>高级”。 “ 高级 ”选项卡是列出代理服务器的位置。 通过完成此任务，在命令提示符下对该代理服务器进行 Ping 操作：
ping 代理服务器并获取阶段 1 到 2 的往返值（以毫秒为单位）
完成以下步骤，运行提升的命令提示符：
单击“开始”。
在 “开始搜索 ”框中键入 cmd，然后按 CTRL+SHIFT+ENTER。
如果出现“用户帐户控制”对话框，请确认所显示的是您想要执行的操作，然后单击“继续”。
键入 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
- 当跟踪停止发送测试数据包时，你将收到一个小摘要，其中列出了平均值（以毫秒为单位），这就是你所追求的值。 创建提示的屏幕截图，并使用命名约定保存它。 此时，使用该值填写关系图可能也有所帮助。
也许你在清晨进行了跟踪，客户端可以快速到达代理 (或任何出口服务器退出 Internet) 。 在这种情况下，数字可能如下所示：
如果客户端计算机是少数有权访问代理 (或) 服务器出口的选择少数计算机之一，则可以通过远程连接到该计算机来运行测试的下一站，并运行命令提示符以从那里将 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 毫秒。
在故障排除方面，你可能会发现一些有趣的东西，只是保留这些基线。 例如，如果发现从代理或出口点到Office 365 URL 的延迟通常约为 40 毫秒到 59 毫秒， 并且客户端到代理或出口点延迟大约为 3 毫秒到 7 毫秒 (具体取决于你在一天中看到的网络流量量) 那么，如果你的最后三个客户端到代理或出口，你肯定会知道有问题基线显示 45 毫秒的延迟。
高级方法
如果你真的想知道 Internet 请求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 for Business，最后一步是在 SharePoint Online 主页 (的负载之间构建一个比较，该主页通常由公司) 和OneDrive for Business主页进行自定义，而主页很少进行自定义。 对于加载速度缓慢的 SharePoint Online 网站，这是一项基本测试。 可以在测试中生成此差异的记录。
如果遇到性能问题，许多步骤都与执行基线时相同。 网络跟踪变得至关重要，因此我们将处理下一步 如何 获取重要跟踪。
若要解决性能问题， 现在需要在遇到性能问题时进行跟踪。 你需要有适当的工具来收集日志，你需要一个行动计划，即要采取的疑难解答操作列表，以收集最好的信息。 要执行的第一件事是记录测试的日期和时间，以便文件可以保存在反映计时的文件夹中。 接下来，缩小到问题步骤本身。 这些是用于测试的确切步骤。 不要忘记基本知识：如果问题仅适用于 Outlook，请确保记录问题行为仅发生在一个Office 365服务中。 缩小此问题的范围有助于专注于可以解决的问题。