如何保证一个请求在 200ms 内完成

2020-08-20 00:26:13 +08:00
 SelectLanguage

我发现查询一张表单独根据 id 条件查询大概要 0.04~0.05 秒 这样如果一个请求需要执行超过 5 个 sql 语句就能很难达到要求了 不知道有没有什么好办法,一个 sql 语句 0.05 秒是太慢了吗?

4086 次点击
所在节点    程序员
20 条回复
wellsc
2020-08-20 00:31:26 +08:00
具体情况具体分析
Jooooooooo
2020-08-20 00:34:20 +08:00
多个线程并发请求

这种 io 是主要瓶颈的逻辑尽可能搞起并发
isukkaw
2020-08-20 00:58:38 +08:00
50ms 这个量级其实很微妙。

该缓存缓存,该并发并发。
hronro
2020-08-20 01:00:25 +08:00
5 个 SQL 能否并行查询,还是之间有依赖关系?是否用了 ORM 之类的东西可能拖慢查询速度?
jiahonzheng
2020-08-20 01:54:34 +08:00
1. 看业务,如果可以缓存,那就上缓存
js8510
2020-08-20 05:13:48 +08:00
sharding. cache. 看看设计能不能提高并发 单一服务能不能拆分然后 fan out 等等等。。 你这个问题太宽泛了。
nvkou
2020-08-20 05:27:30 +08:00
说实话 200 毫秒应该要被考虑到网络波动的量级。要保证 200 不只是数据库问题
fengchang
2020-08-20 06:43:59 +08:00
查询一张表单独根据 id 条件查询大概要 0.04~0.05 秒

----

根据 id 查询 50ms 是有点慢了,但是不知道你的数据库具体情况

ID 是主键吗?
硬盘上 SSD 了吗?
列是不是太多了,所有列都是必要的吗?
opengps
2020-08-20 06:59:26 +08:00
提高硬盘速度
优化 sql
并发提升其实不一定大
kaiki
2020-08-20 07:40:58 +08:00
不知道实际情况不好给建议,不过能优化的大概也就是查询这块了,提前准备好缓存数据把查询省掉的话,能快很多。
594duck
2020-08-20 08:14:03 +08:00
我们问题要一个一个的讲
首先 200ms 这个死线是怎么来的,你监控自己的 API 响应的时候,要区分出 request 和 proxy 的流量,然后要把流量分成 97%,95%,80%,50%,20%.只要 request r95%是小于 200ms 就 OK

第二,关于 SQL 语句,我们也要具体问题具体看,首先,你的 SQL 表有多少行,什么配置,查询一次 40ms 是为什么,他是不是必须这么慢,比如 OLAP 的就这么慢是说的过去的大不了改为异步。但是如果是 OLTP 的数据库,理论上每一个请求必须在 10ms 内完成。具体你要说一下你的架构,数据库配置,数据库最慢的表是什么表,是不是有 cache,有没有读写分离。
594duck
2020-08-20 08:15:36 +08:00
数据库最慢的表有多少行,存的字段是什么样的,一次读取的量大概有多大。

你查一次 40ms,那要扫描多少行,遍历 多少行
594duck
2020-08-20 08:17:08 +08:00
不是很认同上手叫你上什么 SSD,加 IO 硬盘的,属于不懂 RCA 分析法的选手
ericls
2020-08-20 08:18:30 +08:00
不结合业务讨论意义不大 如果你要不惜一切代价的话 拆分成多个请求 总体速度会降低 但是单个请求会快 你愿意吗? 还有个好处 看上去的并发性能会好一些
wangritian
2020-08-20 09:36:55 +08:00
主键查询几十毫秒真的慢了,先在服务器 ping 一下数据库或是用命令行查询看看时间,然后看看数据库的负载是不是太高,另外你做长连接了吗
la2la
2020-08-20 09:46:35 +08:00
网络延迟,数据库 IO,业务逻辑这个三个方面看看哪方面是瓶颈,在针对性的优化。不过一般我碰到的大部分都是数据库 SQL 执行问题
binbinyouliiii
2020-08-20 09:49:12 +08:00
200 毫秒对于前端感知来说还好,比如你用阿里云的控制面板,超过 200ms 是经常的事情
KarlChen2015
2020-08-20 09:56:10 +08:00
主键查询 1ms 足矣
我这是 200 万记录的表
zppass
2020-08-20 10:01:06 +08:00
一般来说几百毫秒还能接受,但是你这 5 个查询,首先要考虑有些不怎么会变的,是不是可以考虑用 redis 存起来,另外优化 SQL,不要出现循环里面套 SQL 的情况。还有就是主键查询,其实蛮快的,考虑一下楼上老哥们的说法排查。
至于并发,实际上你这个请求结果,用户不需要即时感应的话,其实异步多线程就可以了。比如说生成一个人工订单不能马上反馈那种,没必要把东西都搞完再返回。
Yano
2020-08-20 10:01:21 +08:00
如果数据库不经常变动,感觉可以缓存起来,不过根据主键 id 查询的应该很快。同时 sql 只查询必要字段,不用把所有列都返回

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/699769

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX