使用基线和性能历史记录优化 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 支持人员创立案例之前,你可以收集数据并采取一些措施,这些措施将探索并有可能解决你的问题。

重要: 请留意 Office 365 中的容量规划和限制。了解该信息之后,你在尝试解决性能问题的时候可以少走一些弯路。以下是 Office 365 平台服务说明的链接。这是一个中心枢纽,Office 365 提供的所有服务都有一个链接可从此处转到其自己的服务说明。这意味着,如果需要查看 SharePoint Online 的标准限制,可单击 SharePoint Online 服务说明并找到其 SharePoint Online 限制部分

进行故障排除时请确保了解:性能指标会不断浮动,没有办法达到一个理想值并永久保持(如果你认为这是可以实现的,那么偶尔执行高带宽任务时压力会非常大,如大量用户入职或执行大型数据迁移,因此应规划性能影响)。你可以且应该大致了解你的性能目标,然而,许多可变因素影响着性能的发挥,因此具体性能会千差万别。这是性能的本性使然。

性能故障排除并不是指达到特定目标和无限地保持相关数字,而是参照所有可变因素改善现有活动。

不过,性能问题是什么样的呢?

首先,你需要确保你所遇到的问题确实是性能问题,而不是服务事件。 在 Office 365 中,性能问题与服务事件并不相同。 下面介绍区分它们的方法。

如果是 Office 365 服务有问题,就称为服务事件。 你将在 Office 365 管理中心的“当前运行状况”下方看到红色或黄色图标,你可能还会注意到连接到 Office 365 的客户端计算机性能缓慢。 例如,如果当前运行状况报告了红色图标,而你在 Exchange 旁边看到“正在调查”字样,那么你组织中的用户随后可能会接二连三打来电话,投诉使用 Exchange Online 的客户端邮箱跟老牛拉破车一样慢。 在这种情况下,毫无疑义,Exchange Online 性能成了服务问题的牺牲品。

Office 365 运行状况仪表板,所有工作负载显示为绿色,Exchange 除外,它显示“服务已还原”。

此时,你作为 Office 365 管理员应该经常检查“当前运行状况”和“查看详细信息和历史记录”,及时了解我们对系统执行的维护工作。 “当前运行状况”仪表板用于让你了解有关对服务所做的更改和服务问题的最新信息。 一个个管理员写入运行状况历史记录的备注和说明就汇集在这里,以帮助你评估对你的影响并及时了解正在进行的工作。

Office 365 运行状况仪表板的图片,说明 Exchange Online 服务已还原和原因。

性能问题不是服务事件,虽然服务事件可能会导致性能缓慢。 性能问题如下所示:

  • 性能问题的发生,与 Office 365 管理中心“当前运行状况”所报告的服务问题关系不大。

  • 性能问题发生时,以往比较顺畅的行为需要很长时间才能完成,甚至根本无法完成。

  • 如果你执行一系列合适的步骤,你也可以再现该问题,或者至少知道该问题将会发生。

  • 如果问题间歇性出现,也有一定的规律,例如,你知道一到上午 10 点,就会有用户打电话给你,投诉说他们无法可靠地访问 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><what's happening in the test> 是一个良好的开端。 在这方面越细致,以后尝试解决问题时对你越有帮助。 以后,你将能够说“我在 2 月 8 日获得了两个跟踪文件,一个显示了性能良好,一个显示了性能较差,因此我们可以加以比较”。 这对于故障排除极其有帮助。

你需要采用一种有条理的方式来保留历史基准。 在本示例中,简单的方法产生三个命令行输出,结果以屏幕截图方式进行收集,但你可改为收集网络捕获文件。 请使用最适合你的方法。 存储你的历史基准,在注意到联机服务行为发生变化的点参考这些基准。

为何要在试行期间收集性能数据?

没有比 Office 365 服务试行期间开始记录基准更好的时间了。 你的办公室可能有成千上万个用户、数十万用户,也可能只有 5 个用户,然而即使用户数量较少,你也可以进行测试来衡量性能波动。 对于规模较大的公司,试行 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 和 HTTPs

  • 下列 URL 中任意一个 URL 的出站连接:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

需要允许所有用户访问这些地址,而忽略任何代理干扰或身份验证。 在较小的网络上,应该将这些地址添加到你的 Web 浏览器的代理绕过列表中。

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

*.microsoftonline.com; *.sharepoint.com

一旦你绕过代理,应该能够直接在 Office 365 URL 上使用 ping 或 PsPing。 下一步将会测试 ping outlook.office365.com。 或者,如果你使用 PsPing 或允许你向命令提供端口号的另一种工具,请对 portal.microsoftonline.com:443 执行 PsPing 操作,以毫秒为单位查看平均往返行程时间。

往返行程时间 (RTT) 是一个数值,用于测量将 HTTP 请求发送到 outlook.office365.com 等服务器并收到响应确认服务器知道你执行该操作所花的时间。 有时会看到它缩写为 RTT。 这应是相对较短的时间。

必须使用 PSPing 或不使用会被 Office 365 阻止的 ICMP 数据包的另一种工具,才能执行此测试。

如何使用 PsPing 直接从 Office 365 URL 获取整体往返行程时间(以毫秒为单位)

  1. 通过完成下列步骤来运行提升的命令提示符:

    1. 单击“开始”。

    2. 在“开始搜索”框中,键入 cmd,然后按 CTRL+SHIFT+ENTER。

    3. 如果出现“用户帐户控制”对话框,请确认它所显示的操作正是你想要的,然后单击“继续”。

  2. 导航到安装工具(在此示例中为 PsPing)的文件夹并测试下列 Office 365 URL:

    • psping portal.office.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 操作后,请查看平均时间(以毫秒为单位)。 这就是你要记录的内容!

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

如果不熟悉代理绕过,并希望分步执行操作,你需要首先了解你的代理服务器的名称。 在 Internet Explorer 中,转到“工具”>“Internet 选项”>“连接”>“局域网设置”>“高级”。 在“高级”选项卡中,你将看到列出的代理服务器。 完成此任务,在命令提示符处 ping 该代理服务器:

ping 代理服务器并获得从阶段 1 到 2 的往返行程时间值(以毫秒为单位)

  1. 通过完成下列步骤来运行提升的命令提示符:

    1. 单击“开始”。

    2. 在“开始搜索”框中,键入 cmd,然后按 CTRL+SHIFT+ENTER。

    3. 如果出现“用户帐户控制”对话框,请确认它所显示的操作正是你想要的,然后单击“继续”。

  2. 键入 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

  3. 当跟踪停止发送测试数据包时,你会得到一个小总结,以毫秒为单位列出平均值,这就是你想要的值。 获取提示符的屏幕截图并按照命名约定保存它。 此时,用该值填写图表可能作用甚大。

也许你在早上已进行了一次跟踪,而你的客户端能够快速到达代理(或者前往 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 的时间为 62.01 毫秒,那么从代理出口到 Office 365 URL 的平均值为 49.76 毫秒。

其他图形显示从客户端到客户端外部的代理到 Office 365 ping 操作所花的毫秒数,以便可以减去值。

在故障排除方面,你可能会从保留这些基准中发现一些有趣的事情。 例如,如果你发现从代理或出口点到 Office 365 URL 通常有大约 40 到 59 毫秒的延迟,而从客户端到代理或出口点大约有 3 到 7 毫秒的延迟(取决于你在一天的该时间看到的网络流量),那么当最后三个客户端到代理或出口点的基准显示有 45 毫秒的延迟时,你可以确信存在问题。

高级方法

如果确实想知道从 Internet 发送到 Office 365 的请求所发生的情况,则需要熟悉网络跟踪。对这些跟踪使用哪些工具无关紧要,HTTPWatch、Netmon、消息分析器、Wireshark、Fiddler、开发人员仪表板工具或任何其他工具都可以,前提是该工具可以捕获和筛选网络流量。在此部分中你将看到,运行以上多个工具来获取问题的更全面的概况更有好处。执行测试时,其中的一些工具还单独充当代理。配套文章 Office 365 的性能疑难解答计划中使用的工具包括 Netmon 3.4HTTPWatchWireShark

记录性能基准是此方法较为简单的一部分,许多步骤与你在对问题执行故障排除时的步骤相同。 创建性能基准更高级的方法要求你记录和存储网络跟踪。 本文中的大多数示例使用 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 端点

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×