API 请求慢?这次锅真不在后端

简介: API 请求慢?这次锅真不在后端

问题

我们在开发过程中,发现后端 API 请求特别慢,于是跟后端抱怨。

“怎么 API 这么慢啊,请求一个接口要十几秒”。

而且这种情况是偶现的,前端开发同学表示有时候会出现,非必现。

但是后端同学通过一顿操作后发现,接口没有问题,他们是通过 postman 工具以及 test 环境尝试,都发现接口请求速度是没有问题的。

“那感觉是前端问题”?

我们来梳理一下问题,如下:

  • 后端 API 请求特别慢,而且是偶现的。
  • 在 test 环境没有复现。
  • postman 工具请求没有复现。

问题解决过程

时间都去哪了?

第一个问题,API 耗费的时间都用来做什么了?

我们打开 Chrome 调试工具。在 network 中可以看到每个接口的耗时。

hover 到你的耗时接口的 Waterful,就可以看到该接口的具体耗时。

可以看到,其耗时主要是在 Stalled,代表浏览器得到要发出这个请求的指令到请求可以发出的等待时间,一般是代理协商、以及等待可复用的 TCP 连接释放的时间,不包括 DNS 查询、建立 TCP 连接等时间等。

所以 API 一直在等待浏览器给它发出去的指令,以上面截图的为例,整整等待了 23.84S,它请求和响应的时间很快(最多也就几百毫秒,也就是后端所说的接口并不慢)。

所以 API 到底在等待浏览器的什么处理?

什么阻塞了请求?

经过定位,我们发现,我们项目中使用 Server-Sent Events(以下简称 SSE)。它跟 WebSocket 一样,都是服务器向浏览器推送信息。但不同的是,它使用的是 HTTP 协议。

当不通过 HTTP / 2 使用时,SSE 会受到最大连接数的限制,限制为 6 次。此限制是针对每个浏览器 + 域的,因此这意味着您可以跨所有选项卡打开 6 个 SSE 连接到 www.example1.com,并打开 6 个 SSE 连接到 www.example2.com。这一点可以通过以下这个 demo 复现。

复制问题的步骤:

  • 访问ssebin.btubbs.com/multi/
  • 单击添加计数器6或更多次
  • 尝试打开另一个标签到同一地址

结果是,第 6 次之后,SSE 请求一直无法响应,打开新的标签到同一个地址的时候,浏览器也无法访问。

效果图如下:

该问题在 Chrome 和 Firefox 中被标记为“无法解决”。

至于偶现,是因为前端开发者有时候用 Chrome 会打开了多个选项卡,每个选项卡都是同一个本地开发地址,就会导致达到 SSE 的最大连接数的限制,而它的执行时间会很长,也就会阻塞其他的请求,一致在等待 SSE 执行完。

所以解决的方法是什么?

解决方案

简单粗暴的两个方法

  • 不要打开太多个选项卡。这样就不会达到它的限制数。(因为我们一个选项卡只请求一个 SSE)。
  • 开发环境下,关闭该功能。

使用 HTTP / 2

使用 HTTP / 2 时,HTTP 同一时间内的最大连接数由服务器和客户端之间协商(默认为 100)

这解释了为什么我们 test 环境没有问题,因为 test 环境用的是 HTTP / 2。而在开发环境中,我们使用的是 HTTP 1.1 就会出现这个问题。

那如何在开发环境中使用 HTTP / 2 呢?

我们现在在开发环境,大部分还是使用 webpack-dev-server 起一个本地服务,快速开发应用程序。在文档中,我们找到 server 选项,允许设置服务器和配置项(默认为 'http')。

只需要加上这一行代码即可。

devServer: {+  server: 'spdy',
  port: PORT,
}复制代码

看看效果,是成功了的。

原理使用 spdy 使用自签名证书通过 HTTP/2 提供服务。需要注意的一点是:

该配置项在 Node 15.0.0 及以上的版本会被忽略,因为 spdy 在这些版本中不会正常工作。一旦 Express 支持 Node 内建 HTTP/2,dev server 会进行迁移。

总结归纳

原本这个问题认为跟前端无关,没想到最后吃瓜吃到自己头上。提升相关技能的知识储备以及思考问题的方式,可能会方便我们定位到此类问题。

充分利用好浏览器的调试工具,对一个问题可以从多个角度出发进行思考。比如一开始,没想到本地也可以开启 HTTP / 2。后来偶然间想搜下是否有此类方案,结果还真有!

技术分享

1、前端技术导航大全             推荐:★★★★★

地址:前端技术导航大全

2、前端面试题库

推荐:★★★★★

地址:前端面试题库

 

3、开发者颜色值转换工具

推荐:★★★★★

地址 :开发者颜色值转换工具

2、前端边框阴影在线工具

推荐:★★★★★

地址:前端边框阴影在线工具

相关文章
|
1月前
|
JSON API 数据格式
获取商品详情API的请求格式是什么
获取商品详情API的请求格式通常依赖于特定的电商平台或服务提供商,但一般遵循类似的结构。以下是一个概括性的说明,以及针对几个主流电商平台的示例:
|
2月前
|
JSON 缓存 测试技术
构建高效RESTful API的后端实践指南####
本文将深入探讨如何设计并实现一个高效、可扩展且易于维护的RESTful API。不同于传统的摘要概述,本节将直接以行动指南的形式,列出构建RESTful API时必须遵循的核心原则与最佳实践,旨在为开发者提供一套直接可行的实施框架,快速提升API设计与开发能力。 ####
|
2月前
|
JSON API 数据格式
探索后端开发:从零构建简易RESTful API
在数字时代的浪潮中,后端开发如同搭建一座桥梁,连接着用户界面与数据世界。本文将引导读者步入后端开发的殿堂,通过构建一个简易的RESTful API,揭示其背后的逻辑与魅力。我们将从基础概念出发,逐步深入到实际操作,不仅分享代码示例,更探讨如何思考和解决问题,让每一位读者都能在后端开发的道路上迈出坚实的一步。
|
2月前
|
缓存 前端开发 API
深入浅出:后端开发中的RESTful API设计原则
【10月更文挑战第43天】在数字化浪潮中,后端开发如同搭建梦想的脚手架,而RESTful API则是连接梦想与现实的桥梁。本文将带你领略API设计的哲学之美,探索如何通过简洁明了的设计,提升开发效率与用户体验。从资源定位到接口约束,从状态转换到性能优化,我们将一步步构建高效、易用、可维护的后端服务。无论你是初涉后端的新手,还是寻求进阶的开发者,这篇文章都将为你的开发之路提供指引。让我们一起走进RESTful API的世界,解锁后端开发的新篇章。
|
2月前
|
缓存 API 开发者
构建高效后端服务:RESTful API设计原则与实践
【10月更文挑战第43天】在数字化时代的浪潮中,后端服务的稳定性和效率成为企业竞争力的关键。本文将深入探讨如何构建高效的后端服务,重点介绍RESTful API的设计原则和实践技巧,帮助开发者提升服务的可用性、可扩展性和安全性。通过实际代码示例,我们将展示如何将这些原则应用到日常开发工作中,以确保后端服务能够支撑起现代Web和移动应用的需求。
|
2月前
|
存储 JSON 测试技术
构建高效后端API:实践和原则
【10月更文挑战第43天】本文深入探讨了如何设计和实现高效、可维护的后端API,强调了设计哲学、最佳实践和常见陷阱。通过具体示例,我们展示了如何运用这些原则来提高API的性能和可用性。
|
2月前
|
JSON API 开发者
构建高效API:后端开发中的RESTful最佳实践####
在数字化时代,API作为不同系统间通信的桥梁,其重要性日益凸显。本文将深入探讨RESTful API的设计原则与最佳实践,通过实际案例分析,揭示如何构建高效、可维护且易于使用的API接口,助力后端开发者提升项目质量与用户体验。 ####
|
2月前
|
存储 SQL API
探索后端开发:构建高效API与数据库交互
【10月更文挑战第36天】在数字化时代,后端开发是连接用户界面和数据存储的桥梁。本文深入探讨如何设计高效的API以及如何实现API与数据库之间的无缝交互,确保数据的一致性和高性能。我们将从基础概念出发,逐步深入到实战技巧,为读者提供一个清晰的后端开发路线图。
|
2月前
|
JSON 缓存 API
探索后端开发中的RESTful API设计原则
【10月更文挑战第41天】在后端开发的广阔天地中,API的设计如同绘制一幅精细的地图,指引着数据的流向和前端的交互。本文将带你走进RESTful API的世界,一起探索如何用简洁高效的设计原则来构建一个清晰、可维护且易于理解的API结构。我们将从RESTful API的基础概念出发,通过实际案例分析,揭示如何在实践中应用这些设计原则,并讨论如何在复杂的业务逻辑中保持API的简洁性和一致性。
|
2月前
|
安全 前端开发 API
探索后端开发中的API设计原则
【10月更文挑战第41天】在数字化时代的浪潮中,后端开发扮演着至关重要的角色。本文将深入探讨API设计的核心原则,从RESTful API的实现到错误处理的最佳实践,带领读者领略高效、可维护和易于扩展的API设计之美。

热门文章

最新文章