前言

互联网下行带来灵魂追问。

• 钱花哪去了？

• 产出在哪里？

动辄自建的遮羞布逐步显现，不过自建的成本可能还不是最大的负担，掣肘的可能是把不重要的事情当成了主业来做，比如：

• 互联网+

• 比如数字化转型

• 比如研发效率和 devops

• 比如可观测性

本次要“安利”的新功能叫做应用 Span 请求耗时分布显示，建议优先阅读文章：巧用 “ 火焰图 ” 快速分析链路性能

本文主要大纲如下：

1. 简单的功能说明

2. 简单的功能示例

3. 简单的功能讲解

4. 简单的 FAQ

1. 功能说明

注意：用户访问监测 SDK 必须是 2.2.10 以及上才可以看到这部分数据显示

2. demo 演示

先上效果图 

准备阶段

环境：

至于前端系统，我们使用去哪开源的 yapi。

使用开源系统争议比较少，而且开源系统相对比较成熟，有关去哪开源的 yapi 整体大概是 node 做 back end api 的同时也做 web server。

有关 yapi 的展示如下： 

安装步骤

过于简单，参照官网安装即可，不再赘述，同时官网有 docker 镜像，安装也很简单。

• 安装 yapi

• 引入观测云 sdk

安装后效果很简单的展示，之前讲过，此处仅列出截图

服务页面

概览页面

链路页面

链路火焰图

链路 span 列表

服务调用关系

请求耗时分布

3. 请求耗时该怎么看？

这里的请求耗时分布，仿照 chrome tools 中的 timeline 页面，包括

• Queueing（队列）

• First Byte（首包）

• Download（下载） 具体展示见下图。

 这里我们将针对各个部分进行讲解。

名词解释

queueing

排队时间，如果该请求被排队，则这里会大于 0。

first byte

等待响应的时间，具体来说是等待返回首个字节的时间。包含了与服务器之间一个来回响应的时间和等待首个字节被返回的时间。

Content Download

用于下载响应的时间

将这三者结合来看，前端、后端、网络三者之间耗时占比一目了然。

4. FAQ

1. 为什么会排队？谷歌给出的解释如下：

• There are higher priority requests.

• There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.

• The browser is briefly allocating space in the disk cache

翻译一下，如下：

• 有更高优先级的请求。

• 源站已经达到 6 个 TCP 连接上线，针对 HTTP/1.0 和 HTTP/1.1。

• 浏览器配置磁盘缓存

这里有几点需要注意：

• 有更高优先级的请求。

• 源站已经达到6个 TCP 连接上线，针对 HTTP/1.0 和 HTTP/1.1。

• 浏览器配置磁盘缓存
  

2. 解释一 priority

1. 在资源中不同类型有不同的请求级别，比如 html/css/js/xhr 他们的优先级别不一样；

2. 可以更改资源的属性，调整优先级别。

目前有哪些优先级别？

• high: You consider the resource a high priority and want the browser to prioritize it as long as the browser's heuristics don't prevent that from happening.

• low: You consider the resource a low priority and want the browser to deprioritize it if it's heuristics permit.

• auto: This is the default value where you don't have a preference and let the browser decide the appropriate priority.

有关静态资源在网络请求中的优先级别，比较基础，本文暂不讨论；

3. 针对网络请求，优先级别是不一样的。如何调整？

谷歌给出的例子如下：

fetch('https://example.com/', {importance: 'high'})      .then(data => {        // Trigger a high priority fetch      });复制代码

但问题来了，本身 fetch 的默认优先级别是啥？

4. 有关请求连接数，2.0 是救命稻草吗？

因为单个源在 1.0 和 1.1 的连接数量的限制，尽快升级到 2.0，可以解决一定的问题

5. 升级到 2.0 就不会出现 queueing 了吗？

我们以网站升级到 2.0 的 timeline 为例子进行观察。