可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了

时间:2024-01-28 15:15:04

前言

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

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

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

  • 互联网+
  • 比如数字化转型
  • 比如研发效率和devops
  • 比如可观测性

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

本文主要大纲如下:

  1. 简单的功能说明
  2. 简单的功能示例
  3. 简单的功能讲解
  4. 简单的FAQ

1. 功能说明

名称

简单说明

作用

Span 请求耗时分布显示

在链路详情页,若当前的链路属于前端应用调用产生的 Span,在链路详情查看请求耗时分布,包括 Queueing(队列)、First Byte(首包)、Download(下载)的请求信息

直观查看消耗占比

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

2. demo演示

先上效果图

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_优先级_02

准备阶段

环境:

环境

版本

node

v12.16.3

mongo

1.8.4

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

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

有关yapi的展示如下:

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_架构_03

安装步骤

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

  • 安装yapi
  • 引入观测云sdk

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

服务页面

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_优先级_04

概览页面

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_HTTP_05

链路页面

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_优先级_06

链路火焰图

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_架构_07

链路span列表

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_架构_08

服务调用关系

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_HTTP_09

请求耗时分布

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_架构_10

3. 请求耗时该怎么看?

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

  • Queueing(队列)
  • First Byte(首包)
  • Download(下载) 具体展示见下图。

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_链路_11

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

名词解释

queueing

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

first byte

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

Content Download

用于下载响应的时间,谷歌对于这部分内容是这样描述的:

The browser is receiving the response, either directly from the network or from a service worker. This value is the total amount of time spent reading the response body. Larger than expected values could indicate a slow network, or that the browser is busy performing other work which delays the response from being read.

翻译出来,大意基本是:

浏览器在收到网络或者sw的响应后读取响应body的总耗时。超过估计值,可能意味着网络慢,或者浏览器在处理其他事务,相应读取延迟了。

基于经验,我们完全可以理解成:下载时间。

如果把queuing看做浏览器,first byte看做服务器, 结合来看,前端、后端、网络三者之间耗时占比一目了然。

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.0HTTP/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为例子进行观察。

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_优先级_12

这里我们看到再次出现了排队,ssl。

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

6.1 有关下载时间

如果定义

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

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

  • 传输多少数据量这个问题要问:

后端研发、网络工程师:接口平均响应时间应该是多少?

6.2 有关排队
  • 如果有排队,是不是可以取消排队
  • 如果无法取消排队,是不是可以减少排队的数量或等待时间这个问题要问:

前端研发:是否可以不排队或者少排队?

附上一张有关navigation的拆截图,聪明的读者,可以按照timeline来对照一下,看看每一个环节都对应了哪部分内容。

可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了_优先级_14