这是一个创建于 485 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题描述
假设：
- 这里有一个接口，在浏览器控制台中看到他的请求时间是 50ms
- 复制到同网络环境下的 postman 中调用，请求时间是将近 200ms ，请求头完全复制
- 把调用写到 js 脚本中，在同网络环境下 node 运行 ，console.time 显示也是 200ms
怀疑过程
- 一开始以为是 nodejs 瓶颈，在中文互联网下搜索原因寥寥无几，改去 stackoverflow 用 [nodejs is slower than chrome] 查找，有几篇类似的像这一篇，看回答基本都是是归咎于网络；
- 通过 fiddler 查看，有如下区别
- 在 js 脚本中把原本一次运行只调用一次的请求重复调用了几次，发现后几次速度逐渐接近浏览器原生访问
我的问题
- 我怀疑是不是有什么缓存机制在生效，与 fiddler 中的 TCP/IP Connect 和 ServerConnected 的差异相耦合，可惜到这里中文互联网上的资料就明显出现了欠缺，感觉我已经快找到正确的原因了，所以来找大家确认下
- 如果 1 是正确的，那对于每次运行都从头开始的 js 脚本，有什么解决方法吗？ nginx 的缓存配置可以起到作用吗
 |
1
BeautifulSoap 2023-09-03 13:50:46 +08:00 via Android  3
keep alive 吧，chrome 多次请求就自动帮你处理了。nodejs 运行完脚本就停掉了所以打开的端口直接关了需要重开
|
 |
2
hronro 2023-09-03 13:59:17 +08:00
听说 node.js 内置的 http 模块很拉, 在 node.js 里用 shell 去调用 CURL 发请求都比用内置的 http 模块快(听别人说的, 没实际验证过)
|
 |
3
isbase 2023-09-03 14:05:53 +08:00 via iPhone
用 urllib 试试
|
 |
4
L1shen 2023-09-03 14:08:32 +08:00
觉得内置的 http 慢可以试试 uWebSockets.js
|
 |
5
sub166 2023-09-03 16:12:21 +08:00
换成 deno 或者 bun 试试
|
 |
6
zsj1029 2023-09-03 19:38:55 +08:00 via iPhone
进程开销，如果是 koa 常驻内存再试，应该可以稳定
|
 |
7
MrKrabs 2023-09-03 19:58:35 +08:00
盲猜 tcp 连接延迟
|
 |
8
githmb 2023-09-04 10:19:12 +08:00
有没有一种可能，浏览器的请求复用了一个 TCP 连接，你没发现你在 js 脚本里重复调用了几次只有第一次延迟有点高吗？
|
 |
9
mark2025 2023-09-04 13:11:44 +08:00
1. nodejs 环境启动开销
2. http 握手开销 |
 |
10
KiraMaple 2023-09-11 22:14:15 +08:00
@hronro 你看过 nodejs 的架构图就知道了，nodejs 本身调用 http 请求最后也是用 nodejs 内置的 curl 库，c++和 js 的交互应该不算频繁，而且 V8 在跨语言交互这块不算差
|
 |
11
thynson 2023-09-15 09:54:05 +08:00
1. 浏览器的 keep-alive 机制优化掉了连接建立的开销
2. 浏览器默认会开启压缩，而 postman/node.js 默认没有压缩，如果 response body 较大，而且网速不够快的话，会有显著的区别 3. 如果你要测量一个接口的响应时间，最好在服务端测量，浏览器端的测量不可避免的会收到网络的影响 |
Select Language