有多个客户反馈网站操作很卡，后台看接口 Nginx 响应时间 99%请求都在 2s 以内，静态资源用的是 CDN，应该从哪里排查，或者怎么收集哪个请求慢？他们说的是操作很卡，不是网页打开慢，应该是 API 的问题

[auhah]

不是。。。一个请求 2s 已经很卡了吧？

自己试用一下系统具体问题具体分析呗

[D0n9]

首先，客户可能没有能力区分操作很卡和网页打开慢的区别
其次，后端响应 2s 是非常慢了，建议控制在 300ms 以内，可能和 nginx 没关系，是后端代码烂、慢查询等
最后，静态资源虽然在 CDN ，看似请求不会慢，但如果前端代码一样很烂，也会表现出来卡、慢

收集可以看看 sentry ，skywalking

[twofox]

你自己都不清楚为什么卡呀。。。

所以到底是网络太慢了/资源太大了导致的打开缓慢

还是数据请求太慢导致的卡

还是网页自身不合理，DOM 消耗的资源太多导致的卡

我遇到过一个离谱的就是打开后网页一直请求数据，一个请求达到一两个 G 的数据量。整个网页都卡死的

[xuanbg]

我还以为 OP 说的是 2ms ，仔细一看 TM 是 2s 。。。这个响应速度也太离谱了吧。OP 居然认为正常？

[songray]

2s ，你这个网站已经几乎是不可用的状态了。首次进入触发瀑布请求，直接等个七八秒是吧。
至于排查方式：前端用 sentry 做个埋点，对比一下请求时间和返回时间。

[csys]

99%延迟<2s ，假设每个用户到网站上只做一个操作
那这就意味着每 100 个用户里就有一个倒霉蛋体验到最少 2s 的卡顿

你这不是都已经定位到问题了吗，为什么不认呢

[IvanLi127]

按这描述出得换人重写了...一般不能这么拉

哪个请求的响应慢直接在线上的 nginx 里打印下响应时间呗？等一段时间看看不就知道谁慢了。

[shiny]

如果客户可以配合，浏览器可以录制回放，观测性能；不能配合，装个 Clarity ，看用户的操作回放

[Akikiki]

一个两秒，前端并发请求几个嘞。一个页面加载完成需要请求多少个接口，累加起来时间也不短了

[guanzhangzhang]

F12 看下调用时间

[opengps]

注意角色：（幸存者偏差）
[你] 看 nginx 里的日志，起码这些访问能到达。
[用户] 说很卡，有可能根本没访问到你服务器，不产生 nginx

[lambdaq]

页面挂一个日志采集。

[Daybyedream]

让他们 F12 观察下= =

[yinmin]

别用免费的第三方 cdn ，不靠谱。如果用了免费 cdn ，先把资源转到自己网站上试试

[ala2008]

远程一下（ doge

[dishuibaby]

首先看一下 nginx 日志的 这两个时间（"request_time 0.020 ""uptime 0.020"），排除一下是网络延迟，还是后端响应慢。如果是后端响应慢，那就想办法去优化后端代码。
如果不是，就想办法联系客户排查吧。还有你的前段资源文件的大小，理论上只要不是过于离谱，第二次也就不会很慢了。

[salmon5]

让客户换个快一些的网站，问题解决

[tangzui]

有没有可能是 js 写的卡，前段时间用京东云的控制台，网站卡的跟外包做的一样

[Nosub]

提供几个排除思路：

1.查看后端接口查询的速度，是 SQL 查询的速度，是否有慢查询；
2.查看 API 接口返回的文件大小，从服务器到浏览器需要传输的内容越少，速度自然也越快；
3.是否开启了 GZIP 或是 Brotli 压缩，优化第 2 点；

无非就是三个慢，服务器慢，传输慢，客户端慢。

客户端慢首先排除，Nginx 慢也可以排除；

所以剩下的主要就是 1 ，2 ；

另外 CDN 加速了静态资源的下载，但是会拖慢 API 接口，不过影响比较小，可以忽略；

[anjing01]

NGINX 日志通过 Grafana 打印出来：
1.查询状态码是 200 且超过 1s 以上接口，程序员优化这些接口；
2.查询状态码是 499 的接口（客户主动断开），看看是否异常
3.查询其他异常状态码 40x/50x ，进行分析