前言

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

• 钱花哪去了？
• 产出在哪里？

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

• 互联网+
• 比如数字化转型
• 比如研发效率和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为例子进行观察。

6. 每个部分合理时间应该在多少范围内？

6.1 有关下载时间

如果定义

• trans,代表传输的字节数
• tDownload，代表耗时
• tV，代表传输速度

tDownload=trans/tvtDownload=trans/tvtDownload=trans/tv

当tV是不可控时（非专线情况，即便是专线，也受限于基础设施），这个问题，可以等同于在询问，接口要：

• 传输多少数据量

这个问题要问：后端研发、网络工程师

6.2 有关排队

• 如果有排队，是不是可以取消排队
• 如果无法取消排队，是不是可以减少排队的数量或等待时间

这个问题要问：前端研发