服务器计时 - 如何查看 iPlayer 的性能

对于用户来说，了解 BBC iPlayer 网站的加载时长，一直是一个巨大的挑战。幸运的是，浏览器目前有一系列功能可以帮我们弄清楚这件事。开发者工具在分析和监控浏览器性能方面特别有效，但是缺乏足够的方法来显示在从服务器接收响应之前花费的时间， 这就给了“服务器计时”挽救这一问题有了用武之地。
这项功能已经开发了一段时间了，官方的 W3C 版本应用在 Chrome 65上，该版本于上周3月6日发布。 服务器计时可以添加到你的应用程序的响应头中，在浏览器开发者工具中展示(TTFB)时间 ，例如下面截图中 iPlayer 主页中的例子:

iPlayer Chrome 中 Server Timing 数据
上面的截图来自于 Chrome 开发者工具中展示的 iPlayer 网站在 Network 选项卡和请求时间标签内的请求时间。 它向我们展示了，我们的应用程序如何处理请求，在 101.52ms的等待时间中，有 68.53ms 的时间用于服务器计时，意味着有 32.99ms 被神奇的网络消耗了。
如果你仔细看一下规范，就会发现还有很多方式可以帮助你解决问题，而不用担心我们如何去展示数据。 您只需要在 iPlayer 网站上加每个阶段的时间说明。

来自iplayer的服务器计时
如图所示，每个“服务器计时”有两段信息，分号前是名字，后面 dur 是时长的缩写。切记不要展示太多这些值的实际意义，尽量不要在响应中设置 desc 属性用于描述细节。针对 iPlayer, 我们用标题头的第一部分用于做标签，标签内容以毫秒为单位。

Performance Timing API 数据
另一件很酷的功能是，Server-Timing是受 W3C 规范支持的，浏览器将在性能计时 API 中开始支持，可以在应用程序的客户端中检测。 在上面输出的信息中，您可以看到我们前面讨论过的三个值都在导航栏中，在资源响应中添加服务器计时的实体，这意味着您可以获得更多关于初始加载的内容信息。
我们应该如何使用
在 iPlayer 中，我们使用 Express 和 Node.js (有关我们技术的更多信息，请阅读 Richard Wong 的一篇优秀文章) ，作为中间件实现。 首先，我们使用了 Node.js 中的实现计时器:

通过代码的两个打点，帮助我们计算时间差。也可以用于创建基准和其他时间测量工具。process.hrtime 这个作为开始时间，并以[seconds, nanoseconds]的格式生成该时间戳与当前时间戳之间的差异，以存储时间差。为了将其转化为毫秒，下面我们做这样的运算：

将秒数乘以1000，得到毫秒值，等于将纳秒转换为毫秒，然后将其保留小数点后3位。 剩下的就是把它们全部连接起来:

在 Express 中如果你想测量任意一个回路，都应该从第一次请求到响应的时间。为了实现这个功能，我们找不到任何标准的 Express 钩子，所以使用了 on-headers 的 npm 模块在发送前拦截响应。此时，我们需要注意，我们要使用 res.append 而不是 res.set，使得 Server-Timing headers 内容追加。
展望未来
我们可以想到更多的应用场景，比如使用了两个包含 runningTimers 和 finishedTimers 的映射，这样我们就可以在必要时轻松地添加更多的计时。可以通过添加serverTimingStart 和 serverTimingEnd 这两个方法到 res 对象，这意味着我们可以测量任何我需要测试的代码，例如:

这样就可以在任意片段添加 Server-Timing 数据。同时我们也很想将这些数据添加到控制台上，为了实现这个功能，可以把 hook 方法作为中间件传给 res.append 方法，传参数 req, key 和 value。

如果您对快速添加 Server-Timing 到您的 express 应用程序感兴趣，请尝试 express-simple-timing 模块！
很多其他有趣的用途
如果你有响应缓存，想查看你的服务器花了多长时间加载，它还是很有用的，这样你就知道那个没有用缓存响应功能的小可怜需要等待多长时间了。

有缓存的Server-Timing
通过向响应中添加缓存信息，您可以帮助告知开发人员是否需要关注某些值。 如果您不希望这些值可用，还可以过滤掉这些值。下面是一个在 Varnish 缓存服务器中使用 header vmod 的示例:

或者使用一些默认的 nginx 服务器缓存变量更简单:

W3c 规范的另一个例子是添加关于响应路由到哪个数据中心的信息。这实际上并不像你想象的那么有用，而是像这样出现在开发者工具中:

Chrome 开发工具中的Server Timing描述
上面用 gb 来代表 Server Timing 的 header 的 dc;desc=gb。当然你仍然可以查看完整的性能 API。
结语
花一些时间将这些headers添加到应用程序，开发人员就可以很容易地看到为什么服务器响应变慢了。在 headers 追加这些信息，了解 TTFB 的具体细节。非常感谢 Harry Roberts，他提到了服务器计时信息的问题，和我们一起研究了目前的方案！
加入我们
如果您对我们在这里讨论的内容感兴趣，那么您可以申请加入我们的 Web 团队。 我们一直在寻找有热情的工程师加入我们。

原文链接：https://medium.com/bbc-design-engineering/server-timing-in-the-wild-bfb34816322e