Internet Explorer 性能实验室：切实评测浏览器性能

本博客的主要目的之一是从幕后角度向您介绍我们在 Windows 8 工程中进行的各种努力。本文中，我们将探讨一个工程师和最终用户都在密切关注的问题：实际的 Web 性能。在构建高性能 Web 浏览的过程中，为了弄清各种传闻和使用体验的根本原因，我们投入了大量精力。本博文由来自 IE 团队的 Matt Kotsenas、Jatinder Mann 和 Jason Weber 共同撰写，性能是该团队的每名成员都在奋力追求的目标。--Steven

Web 性能与所有人都息息相关，因此 Internet Explorer 工程目标之一就是成为全世界速度最快的浏览器。为了实现这一目标，我们需要通过用户关心的实际情境，切实地评测浏览器的性能。在过去的五年时间中，我们设计并建造了 Internet Explorer 性能实验室，这是全球最精密的 Web 性能评测系统之一。

IE 性能实验室通过收集可靠、准确且可参考的数据，为整个开发周期内的决策提供依据。每天，我们会对 Internet Explorer 的性能进行 200 次评测，收集到的评测结果超过 570 万条，运行时数据多大 480GB。我们了解每次更改对产品产生的影响，并确保 Internet Explorer 只会变得原来越快。本博文将详细介绍 IE 性能实验室的设计，以及我们如何利用该实验室持续提升体验的 Web 速度。

在本博文中，我们将介绍：

• IE 性能实验室概况
• 实验室基础设施
• 评测内容（方式）
• 情境测试
• 结果调查
• 第三方软件测试
• 为用户构建快速浏览器

IE 性能实验室概况

为了对 Web 性能进行长期的可靠评测，系统必须能够重复模拟实际的用户情境。本质上，我们的系统需要创建一个“迷你版 Internet”。

IE 性能实验室是一个私有网络，与公共 Internet 和 Microsoft 内部网络完全隔离，其中包含 140 多台计算机。该实验室配有实际 Internet 所需的关键组件，包括 Web 服务器、DNS 服务器、路由器和网络模拟器，因此可以模拟各种不同的客户连接情境。

咋看之下可能比较复杂，但这种方法可以排除所有差异因素。通过控制网络的每个环节，下至每个数据包的跳跃和延迟，我们的测试具备了确定性和可重复的特质，这对于获得可供参考结果非常重要。在 IE 性能实验室中，我们使用 100 纳秒的解析度对活动进行评测。

此类网络配置还提供了极大的灵活性。由于要模拟实际设置，因此我们的实验室可以适应几乎所有类型的测试机或网站内容。IE 性能实验室支持所有使用 x86、x64 和 ARM 处理器的台式机、便携式计算机、上网本和平板电脑。同样，因为该实验室使用了 Windows 性能工具（Windows Performance Tools，WPT），所以，我们可以使用其他 Web 浏览器、工具栏、防病毒产品或其他第三方软件运行相同的测试，并直接对比结果。

WPT 可以深入监控底层硬件。借助 WPT，我们可以捕获从 CPU 和 GPU 活动等高层活动，到缓存效率、网络统计数据和内存使用模式等低层活动的各种信息。通过 WPT 我们可以跨堆栈评测和优化性能，确保硬件、设备驱动程序、Windows 操作系统和 Internet Explorer 同时实现高效优化。

运行一次测试需要 6 个小时，这段时间内，将生成超过 22GB 的数据。这一高度自动化的系统只需一个小型团队提供支持，该团队负责监控运行、分析结果和开发新的基础设施功能。

实验室基础设施

性能实验室的基础设施可以分为三个主要类别：网络和服务器、测试客户端以及分析与报告。每个类别旨在最大程度地降低各组件间的交互，这种设计一方面可以提高测试的可扩展性，另一方面也降低了给实验室环境带来噪音的可能性。

上图是 IE 性能实验室内的情景，其中布满了接入私有网络的大量测试和分析用机。

网络和服务器基础设施

首先，我们来讨论 DNS 服务器、网络模拟器和内容服务器，这三者一起组成了我们的迷你 Internet。接下来的三个小节，我们将按照从右至左的顺序介绍该架构图。

内容服务器

内容服务器是 Web 服务器，它代表了 Internet 上的无数 Web 主机。每个内容服务器中都托管着捕获到本地的实际网页。捕获的网页都会经历一个我们称之为“卫生处理”的过程，这一过程中，我们会对网页内容的各个部分进行调节，以确保可供重复判断。例如，JavaScript 日期功能或 Math.Random() 调用将被替换为静态值。此外，由广告框架创建的动态 URL 将锁定为该框架第一次使用的 URL。

卫生处理后，内容将转变为类似静态的内容，并送入 ISAPI 过滤器转变成静态内容，该过滤器会将 URL 的哈希值映射到内容，以便于即时查找。为最大限度降低差异性，并确保内容处于内存中（无需访问硬盘），每个 Web 服务器都是一台具有 16GB RAM 的 16 核计算机。

内容服务器还可以托管动态 Web 应用程序，例如，Outlook Web Access 或 Office Web Apps。在这些情况下，应用程序服务器和任何多层依存关系都将托管到实验室的专用服务器上，与实际环境完全一致。

网络模拟器

由于从源头上消除了许多差异性，因此网络速度将无法反映众多使用低速连接的用户的体验。为了模拟用户的实际环境，测试可以利用网络模拟来了解其在当前使用的各种网络中的性能。该实验室可以模拟多种 DSL 配置、电缆调制解调器、56k 调制解调器以及诸如 WAN 和 4G 环境的高带宽、高延迟环境。HTTP 申请传递到模拟器后，模拟器会模拟诸如数据包延迟和重组这样的网络特征，然后将该申请转发到 Web 主机。收到响应后，会再次应用模拟，然后将模拟传回测试客户端。

使用专用硬件进行网络模拟，不仅可以提供最实际的测试环境，而且可以大幅降低观察者效应。相对于代理或基于软件的解决方案，专用硬件的成本和复杂性都比较高，但这却是准确评测性能的唯一方法。浏览器对并发的代理连接数量进行限制，以防止代理饱和，因此使用代理进行网络模拟会产生回避域名碎片这一意外结果和由网页进行的其他优化。此外，本地网络模拟将与浏览器竞争本地计算机资源，对于低能耗计算机尤为明显。

DNS 服务器

与实际 DNS 服务器一样，该实验室的 DNS 服务器会将内容服务器与测试客户端连接起来。该实验室还会针对每个网络模拟器使用不同的 DNS 服务器，这意味着从一种网络速度更改为另一种网络速度只需更换一个 DNS 服务器。在这些情况下，DNS 服务器会将所有域名解析到关联的网络模拟器，而不是将域名解析到 Web 主机。

测试客户端配置

我们希望确保 Internet Explorer 无论在何种类型的计算机硬件上都能持续高速运行。该实验室拥有超过 120 台专门用于评测 Internet Explorer 性能的计算机。我们称这些计算机为测试客户端，这些计算机从高端 x64 台式机，到低能耗上网本，再到触控优先的平板电脑设备，应有尽有。由于可重复性对于评测至关重要，因此所有测试客户端都采用物理计算机。

Internet Explorer 性能实验室更改对比计算机池

计算机的类型虽然不同，但都包含独立和集成图形平台，以确保 Internet Explorer 能够跨设备生态系统持续利用硬件加速的优势。上图展示了我们的主计算机池。这些 PC 的性能接近用户在 Windows 7 或 Windows 8 PC 的整个生命周期中的一般体验。这些计算机全部从 OEM 订购，以确保一致性；它们出自于相同的制造批次，并且其性能特点在使用前都经过了检查。

该实验室全天候运行，硬件故障在所难免。如果使用其他制造批次中的相同零部件更换发生故障的部件，通常会导致维修过的计算机比池中的其他计算机的运行速度更快。这一差别在实际环境中不明显，但使用 100 纳秒这样低的解析度评测时，数个周期也会影响最终结果！如果某台计算机在维修后，运行速度与池中的其他计算机产生差异，我们会将该计算机从池中撤出，池的大小将因此不断收缩。为解决此问题，实验室专门采购了“备用”计算机，这样，从池中撤走发生故障的计算机后，备用的计算机将提供缓冲，从而避免对实验室的运作产生影响。

为了扩展硬件范围，我们还准备了其他计算机池，以运行各种的用户情境。在这些计算机上的良好表现，可以确保 IE 跨整个 PC 生态系统有效利用底层硬件。

低能耗测试机。每台测试机各用于不同的测试情形。

如果有更高的多样性需求，IE 性能实验室还可以使用 Windows 图形实验室。Windows 图形实验室备有几乎全部已生产的图形芯片组。PC 可以配置为几乎任何可能的组合，然后用于性能测试。在跨芯片组和驱动程序版本诊断图形问题方面，Windows 图形实验室发挥着不可或缺的作用。

分析和报告服务器

测试结果的收集和分析是两个相互独立的步骤。将分析转移到专用的计算机，测试客户端可以尽快启动下一个性能测试，而性能更强大的服务器级计算机可以用来更快地执行分析。分析完成得越快，识别性能变化的效率也就越高。

在分析方面，我们使用 11 台服务器级计算机，其中每台计算机都是使用 16GB RAM 的 16 核计算机。分析过程中，将检查每一个跟踪文件，提取数以千计的指标，并将其输入 SQL 服务器。在一天内，这些分析计算机将检查 15,000 多个用于趋势分析的跟踪文件。

上图为多个服务器机架中的两个，这些服务器机架中装有文件服务器、一台 SQL 服务器及多台分析和内容服务器。

SQL Server 用于存储我们每天收集的近 600 万条评测结果，它是一台使用 64GB RAM 的 24 逻辑核计算机。可以直接通过 SQL 生成报告，也可以使用基于 HTML 的比较应用程序或能提供 XML 或 JSON 格式结果的 WCF 服务对结果进行分析。

评测内容（方式）

介绍过基础设施后，我们将继续讨论性能实验室中评测的各种情境，以及用于手机指标的各种工具。

每日的评测情境

性能实验室重点关注对用户意义重大的实际情境。因此，我们每天会运行超过 20,000 个各类测试。这些测试分为四类（有时会重叠）：

加载内容 — 从一个页面导航到另一个页面仍然是 Web 浏览器中最常见的活动。加载 Web 内容也是唯一触及浏览器 11 个子系统中大部分的类别。加载 Web 内容是其他几个情境类别的先决条件。

交互式 Web 应用程序 — 这一类别涵盖了有时称为内容创建、AJAX 应用程序或 Web 2.0 网站的应用程序。它包括与常用新闻和社交网络站点的交互，以及与诸如 Outlook Web Access 和 Office Web Apps 这样的邮件和文档应用程序的交互。

IE“应用程序” — 重要但却常被忽视的一个类别，它是指与浏览器本身交互的情境。常见的交互包括：打开或关闭浏览器、选项卡切换、使用诸如“历史记录”和“收藏夹”这样的浏览器功能、使用键盘和鼠标进行平移和缩放以及触控输入。

复合基准测试 — 不易被忽视但却常被夸大的一种类别，是指诸如 WebKit SunSpider 这样的复合基准测试。基准测试是一种实用的工程工具，它们会对浏览器的各个子系统施加压力，并突显浏览器之间的差异。但是，为了最大化这些差异，基准测试往往会仰赖非典型的使用模式或极端情况。

实际模式

评测性能时，确保测试反映实际的使用模式至关重要。大多数软件工程教科书都将这一过程称为负载建模或应用程序使用建模。为了确保评测实际模式，性能实验室使用了能体现实际模式且利用不同浏览器子系统的实际网页。

为了确定使用哪些站点进行测试，我们会定期对大量网站进行抓取，并汇总一份站点属性和编码模式的列表。我们使用 68 种不同的数据点来判断站点间的共性，例如，生成 DOM 的深度和宽度、CSS 布局模式、使用的通用框架、国际化功能等。我们会从这些结果中挑选那些最能体现通用模式和更广泛 Web 多样性的站点。

工程指标

性能是一个涉及多方面的问题。要想准确地了解性能，方法只有一个，那就是熟悉正在测试的情境以及硬件和操作系统与浏览器的交互方式。下面我们以首次加载一个流行的体育网站为例，详细讨论五个重要的性能指标。

显示时间 — 显示时间用于评测用户从执行一个操作到在屏幕上看到该操作结果所用的时间。

占用时间 — 大部分站点都会在内容显示到屏幕上后，继续执行后台工作。例如，从 Web 邮件应用程序中下载下一封电子邮件，或将分析数据发回给提供程序。在用户看来，该站点可能已经关闭，但在此过程中通常会产生大量的负载，进而影响整体响应能力。

CPU 时间 — 现在的 Web 浏览器几乎无一例外地受制于 CPU 速度。将负载转移到 GPU 并提高 CPU 效率会显著改善性能。

资源利用率 — 为了构建快速浏览器，需要确保 PC 上的所有资源能够很好地协同运行，包括网络使用率、内存使用模式、GPU 处理能力、图形、内存及无数其他因素。用户在使用 PC 时会同时运行多个应用程序，因此，对浏览器来说，可靠地与其他应用程序共享这些资源至关重要。

能耗 — 在移动情境中，提高电源效率会延长电池的使用寿命，降低设备的用电成本，减小对环境的影响。

过分关注某个指标，我们就会片面地看待性能。如果仅关注某项指标，人们就会很自然地针对这项指标进行优化，而往往以牺牲其他同等重要的指标为代价。消除这种习惯的唯一方法是评测性能的各个方面，然后有意识地作出权衡，而不是不明就里地作出判断。

性能实验室评测的指标总计超过 850 个。每个指标代表浏览器总体性能的某个方面。为了让您对我们的评测对象有个大致了解，以下列出了部分关键指标：私有工作集、全部工作集、HTTP 请求计数、接收的 TCP 字节数、加载的二进制文件数量、上下文切换数量、DWM 视频内存使用情况、GPU 利用率百分比、绘图量、JavaScript 垃圾集合中的 CPU 时间、JavaScript 分析中的 CPU 时间、DWM 更新平均间隔、全部工作集峰值、堆栈分配数量、堆栈分配大小、未完成堆栈分配数量、未完成堆栈分配大小、布局子系统中的 CPU 时间、格式化子系统中的 CPU 时间、呈现子系统中的 CPU 时间、HTML 分析子系统中的 CPU 时间、CPU 空闲时间、线程数。

Windows 事件跟踪基础架构

我们使用 Windows 事件跟踪基础架构 (ETW) 和 VMMap 收集指标。ETW 是 Windows 内部的事件跟踪日志记录系统，许多 Windows 组件和第三方应用程序都在使用它，包括 Windows 事件日志。ETW 日志记录 API 非常简单，开销也非常低，在性能测试中具有关键的作用。

WPT、xperfview.exe 中包含的跟踪查看器是一个功能强大的可视化程序，它可以纠正和覆盖内核、CPU、GPU、I/O、网络和其他事件。WPT 还支持堆栈浏览。堆栈浏览会定期为程序的调用堆栈拍摄快照，并将堆栈另存为跟踪的一部分。通过将 ETW 事件与堆栈相关联，WPT 不仅可以显示正在执行的工作，而且可以显示与该工作相关的调用堆栈以及执行该工作所用的时间长度（使用 10 微秒的解析度）。堆栈浏览可以在任何进程中启用，哪怕是不使用 ETW 事件的进程。堆栈浏览的缺点在于需要调试符号才能解码堆栈，且容易受失真影响。

情境测试

万事俱备，最后一步就是实际的测试流程了。测试可以分为 3 个阶段：设置、测试以及错误和清理。下面是整个流程遵循的流程图。

设置

当某个用户通过实验室网站或自动化框架请求某个运行时，即标志着该流程启动。该运行将和其他正在等待的运行一起放入优先级队列。当某台测试客户端可用时，它会检查队列，并启动可以测试的优先级最高的作业。首先，测试客户端会安装指定的测试操作系统。IE 性能实验室支持基于 Vista、Windows 7 和 Windows 8 的测试。测试客户端会针对每一次运行安装全新的测试操作系统，因此计算机总是会在确定良好的状态下启动。

测试操作系统安装完毕后，客户端将配置 WPT、VMMap 和测试装置。同时，运行还会指定多种 IE 设置，例如主页、建议网站的使用、InPrivate 浏览等。此时还会安装并配置所有第三方软件。

测试前的最后一步是确保测试客户端空闲，以最大限度减少测试冲突。Windows 定义了空闲任务的概念。空闲任务是一种方法，Windows 和其他开发人员借助这一方法可以将不重要的工作安排到以后执行，以避免用户争用资源。操作系统空闲任务包括预获取或 SuperFetching、磁盘碎片整理、更新搜索索引等，具体取决于操作系统版本和配置的服务。为确保测试过程中不执行空闲工作，需要刷新空闲任务队列。此外，Windows Defender 将暂停，并且用于测试装置的日志位置将标识为已从 Windows 索引服务中排除，以防止日志和跟踪文件导致索引器在测试运行期间启动。测试通过多个通路完成，这是为了最大限度减少所需的供应商数量，因为过多的供应商会加大观察者效应。第一条通路通常是暖机通路。暖机可确保浏览器二进制文件“热起来”，且 WinINET 缓存中有最大量的可缓存网页内容可用。后续的每个通路负责一种特定类型的检测，例如，堆栈浏览、内存跟踪和 I/O 及注册表跟踪。

错误和清理

测试过程中一旦浏览器崩溃，则可能是测试通路发生了故障，并且运行转入了下一个测试通路。测试过程中一旦 Windows 崩溃，则计算机将重启，并因为无法保证操作系统的状态而重新安装操作系统。如果重试次数超过了阈值，则整个运行可能会失败，并且计算机会转入另外一个运行，以防止计算机无休止地尝试测试不稳定版本。

所有测试用例结束后，测试客户端会上传供分析使用的日志和跟踪文件。然后，测试客户端会返回到空闲状态，并开始为下一个运行进行轮询。

结果调查

每发生一次更改，都会对所有指标跟踪一次。对于每个测试用例，我们至少运行十次，并在至少两台不同的计算机上重复运行，以便创建抽样总数。借助统计工具，非典型性结果可以自动标识出来，以供检查之用。差异变化也可看作一种回归。用户在与 IE 交互时可能会碰到各种情况，也会用到各种硬件，所以我们的目标之一就是确保客户每次都能获得顺畅、可预期的体验。

除了自动化分析，还有一个分类小组负责检查每天的结果，以监测趋势和其他令人关注的行为。许多统计工具都假定正态分布以及所有样本都是相互独立的，所以有的时候必须进行人工检查。对于我们的测评来讲，任何一种假定都不是绝对正确的。有些活动由操作系统的计时器控制，所以，结果也受页面加载开始时间（遵循计时器周期）的影响。页面加载如果正好在计时器中断前后开始，那么页面加载可能会执行更多或更少的工作，这是因为在页面加载过程中，IE 必须在不同的点响应这种中断。这种中断可能会产生连锁反应，引起双峰分布。另外，由于我们使用了重复试验（并且我们不会在两个迭代之间擦除计算机），所以前一个试验会影响到下一个试验。下面是 Bing 地图的“占用时间”示例图，从此图上可以看出每次更改后占用时间的变化。

红色曲线显示的是各个测试运行的中值，灰色条柱表示范围。将鼠标指针悬停在某个测试运行上将显示指标的迭代（以蓝色显示）和一个提示框，其中显示了精确的最小值、中值和最大值以及相对于前一个测试运行的绝对差异和相对差异。上图中的提示框还显示了其他内容，例如所测试的版本，以及一个指向我们的源控制系统的快速连接，通过它可以查看版本变化。

自动分析与人工检查相结合为 IE 团队进行性能调整提供了可靠、可行的数据。

第三方软件测试

许多第三方应用程序都基于 Trident、网络堆栈和其他 IE 组件。像 BHO 这样的扩展插件以及工具栏会加载到 IE 环境中。其他应用程序（例如安全软件）会将自身插入到 IE 组件中。这些应用程序会变成 IE 堆栈的一部分，而这可能会导致 IE 性能降低。该性能实验室能够评测出第三方软件在受控环境中对实际内容浏览产生的影响。因为用户一般无法量化流行软件对其浏览体验的影响，所以，这些研究对于 IE 及其生态系统来说至关重要。

在测试第三方软件的影响时，我们将已安装第三方软件的运行与仅安装了 IE 的清洁运行进行比较，以此确定该软件产生的影响。我们尤其关注对以下两项指标的评测：启动时间和导航时间。启动时间用于评测浏览器启动并导航到某个 URL 所用的时间，而导航时间用于评测浏览器启动后导航到某个 URL 的时间。启动时间还包括第三方应用程序加载其 IE 扩展插件所用的时间。

使用缓存内容可以让我们在评测过程中进行重复操作。另外，通过评测缓存的站点，我们还可以确切地知道性能回归是由第三方软件造成的，而不是因为站点的不同。每当评测第三方软件的影响时，我们还会通过测试直接连接 Internet 时的启动和导航来验证我们的评测结果，以此证实测试环境不会导致任何增量。

许多第三方应用程序在页面导航期间会将工作转移到云服务。并行工作和使用云服务对于提高性能来说的确是一个非常好的方法，但某些应用程序需要同时等待网络给出的结果，而这将妨碍此流程中的导航。许多实际情境（例如，严格的防火墙、WAN 连接和脱机情境）的模式可能会导致用户感觉性能低下。第三方软件任何时候都不应同时处理对 IE 或用户操作的响应，而应当分批处理 UI 和 DOM 更新，以最大限度减少中断。

为用户构建快速浏览器

浏览器的实际性能是件大事。大规模评测性能是一件耗资巨大的全职工作，但结果证明我们付出的努力都是值得的。Internet Explorer 性能实验室收集的数据对于我们了解浏览器性能和 PC 基础硬件，以及为用户创造快速、流畅且响应及时的 Web 体验具有非常大的帮助作用。

Matt Kotsenas、Jatinder Mann 和 Jason Weber，来自 Internet Explorer 性能团队