问题:两种不同的方式请求接口,输出结果是一样,如果发现两种在耗时上有差异,差异上的数据问题在哪里?一起来探讨下。

对比:取同一个接口count.do_收集数据,

     ①下图是通过HttpClient的方式请求,计时都在100ms左右

  ②下图是浏览器请求接口count.do_,计时如图

连续请求了几个页面得出下面表格

页面 总耗时 Queueing Stalled Request sent Waiting (TTFB) Content Download
监控页 1.95s 0.34ms 0.45ms 0.11ms 1.91s 37.73ms
首页 893.18ms 0.5ms   115.83ms 79us 776.29ms 0.48ms
人员管理页 1.03 s 0.34 ms 128.06 ms 90 μs 787.83 ms 111.20 ms
审计日志页 915.49 ms 0.63 ms 0.63 ms 77 μs 913.81 ms 0.56 ms
参数设置页 778.97 ms 0.35 ms 0.47 ms 0.15 ms 777.41 ms 0.58 ms

 

 

 

 

 

时间细分阶段说明(对上面浏览器各参数解读意思)

以下是有关在 Timing 标签中可能看到的各阶段的更多信息:

  • Queueing浏览器在以下情况下对请求排队

    • 存在更高优先级的请求。
    • 此源已打开六个 TCP 连接,达到限值。 仅适用于 HTTP/1.0 和 HTTP/1.1。(批注:大部分页面都是超过6个接口的)
    • 浏览器正在短暂分配磁盘缓存中的空间
  • Stalled请求可能会因 Queueing 中描述的任何原因而停止
  • DNS Lookup。 浏览器正在解析请求的 IP 地址。
  • Proxy negotiation。 浏览器正在与代理服务器协商请求。
  • Request sent。 正在发送请求。
  • ServiceWorker Preparation。 浏览器正在启动 Service Worker。
  • Request to ServiceWorker。 正在将请求发送到 Service Worker。
  • Waiting (TTFB)浏览器正在等待响应的第一个字节。 TTFB 表示 Time To First Byte(至第一字节的时间)。 此时间包括 1 次往返延迟时间及服务器准备响应所用的时间
  • Content Download浏览器正在接收响应。
  • Receiving Push。 浏览器正在通过 HTTP/2 服务器推送接收此响应的数据。
  • Reading Push。 浏览器正在读取之前收到的本地数据。

 分析

  ①在上面的表格中,stalled明显比较高,产生时间达到上限的tcp的连接,是接口等待时间连接

  ②Waiting (TTFB)在每次请求的时间都是占比非常高的,这里延迟比较高的可能性,也有浏览器处理等待响应时间浏览器问题的可能

最后,加了很多与浏览器相同的请求头,但是请求耗时依旧变化不大

所以,暂时得出结论,这种httpclient无法完全和浏览器请求相同,毕竟客户端和服务端之间有网络开销,您怎么看?欢迎有不同见解,请在评论区留言。

 

 

 

版权声明:本文为zhikou原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/zhikou/p/10397021.html