1
auhah 90 天前
不是。。。一个请求 2s 已经很卡了吧?
自己试用一下系统具体问题具体分析呗 |
2
D0n9 90 天前
首先,客户可能没有能力区分操作很卡和网页打开慢的区别
其次,后端响应 2s 是非常慢了,建议控制在 300ms 以内,可能和 nginx 没关系,是后端代码烂、慢查询等 最后,静态资源虽然在 CDN ,看似请求不会慢,但如果前端代码一样很烂,也会表现出来卡、慢 收集可以看看 sentry ,skywalking |
3
twofox 90 天前
你自己都不清楚为什么卡呀。。。
所以到底是网络太慢了/资源太大了导致的打开缓慢 还是数据请求太慢导致的卡 还是网页自身不合理,DOM 消耗的资源太多导致的卡 我遇到过一个离谱的就是打开后网页一直请求数据,一个请求达到一两个 G 的数据量。整个网页都卡死的 |
4
xuanbg 90 天前
我还以为 OP 说的是 2ms ,仔细一看 TM 是 2s 。。。这个响应速度也太离谱了吧。OP 居然认为正常?
|
5
songray 90 天前
2s ,你这个网站已经几乎是不可用的状态了。首次进入触发瀑布请求,直接等个七八秒是吧。
至于排查方式:前端用 sentry 做个埋点,对比一下请求时间和返回时间。 |
6
csys 90 天前
99%延迟<2s ,假设每个用户到网站上只做一个操作
那这就意味着每 100 个用户里就有一个倒霉蛋体验到最少 2s 的卡顿 你这不是都已经定位到问题了吗,为什么不认呢 |
7
IvanLi127 90 天前
按这描述出得换人重写了...一般不能这么拉
哪个请求的响应慢直接在线上的 nginx 里打印下响应时间呗?等一段时间看看不就知道谁慢了。 |
8
shiny 90 天前
如果客户可以配合,浏览器可以录制回放,观测性能;不能配合,装个 Clarity ,看用户的操作回放
|
9
Akikiki 90 天前
一个两秒,前端并发请求几个嘞。一个页面加载完成需要请求多少个接口,累加起来时间也不短了
|
10
guanzhangzhang 90 天前
F12 看下调用时间
|
11
opengps 90 天前
注意角色:(幸存者偏差)
[你] 看 nginx 里的日志,起码这些访问能到达。 [用户] 说很卡,有可能根本没访问到你服务器,不产生 nginx |
12
lambdaq 90 天前
页面挂一个日志采集。
|
13
Daybyedream 90 天前
让他们 F12 观察下= =
|
14
yinmin 90 天前
别用免费的第三方 cdn ,不靠谱。如果用了免费 cdn ,先把资源转到自己网站上试试
|
15
ala2008 90 天前
远程一下( doge
|
16
dishuibaby 90 天前
首先看一下 nginx 日志的 这两个时间("request_time 0.020 ""uptime 0.020"),排除一下是网络延迟,还是后端响应慢。如果是后端响应慢,那就想办法去优化后端代码。
如果不是,就想办法联系客户排查吧。还有你的前段资源文件的大小,理论上只要不是过于离谱,第二次也就不会很慢了。 |
17
salmon5 90 天前
让客户换个快一些的网站,问题解决
|
18
tangzui 90 天前
有没有可能是 js 写的卡,前段时间用京东云的控制台,网站卡的跟外包做的一样
|
19
Nosub 90 天前
提供几个排除思路:
1.查看后端接口查询的速度,是 SQL 查询的速度,是否有慢查询; 2.查看 API 接口返回的文件大小,从服务器到浏览器需要传输的内容越少,速度自然也越快; 3.是否开启了 GZIP 或是 Brotli 压缩,优化第 2 点; 无非就是三个慢,服务器慢,传输慢,客户端慢。 客户端慢首先排除,Nginx 慢也可以排除; 所以剩下的主要就是 1 ,2 ; 另外 CDN 加速了静态资源的下载,但是会拖慢 API 接口,不过影响比较小,可以忽略; |
20
anjing01 89 天前
NGINX 日志通过 Grafana 打印出来:
1.查询状态码是 200 且超过 1s 以上接口,程序员优化这些接口; 2.查询状态码是 499 的接口(客户主动断开),看看是否异常 3.查询其他异常状态码 40x/50x ,进行分析 |