我自己用 jmeter 压测公司的测试服务器时,很简单的接口(访问数据库+redis 缓存+打 log ),200 的 qps 就会很不稳定,有 5%的请求的延迟就会到 200ms 以上,当然,用来测试的服务器的性能好像很差(具体配置我也没看),而且我用 jmeter 的方法可能也有问题(直接在开发机的 window 下用 gui 测,还不是同一个内网,不过直接用 linux 测好像也没什么区别)
但现在我看有些文章写单机能做到 4 万 qps ( https://zhuanlan.zhihu.com/p/377795008 ),感觉跟我经验差别好大,而且测试单机 qps 应该也不需要分布式测试,毕竟服务器都只有一台,测试怎么会需要多台物理机?
假设接口就是简单的访问一次数据库(假设数据库速度稳定在 2ms )+一次 redis+打 log,95%请求的响应时间在 100ms 以下,普遍情况下单机会有多少 qps ?具体机器配置就需要各位说明一下,当然,也可以提供以下其他条件下的参考值。
我面试时一直写的是单机 qps200,感觉问题真是大。。。。
1
Rocketer 2021-06-04 13:24:11 +08:00 via iPhone
逻辑不同,有什么可比的呢?
我司的核心服务只有 30QPS,三台服务器负载均衡支撑百万日访问量很稳 |
2
Vegetable 2021-06-04 13:24:19 +08:00
我刚写代码第一年用 django 写的服务,请求第三方服务+数据库操作,都不只 200qps 。
你这个情况太模糊,「打 log 」是打印 log 吗?打印到控制台是有可能影响性能的,关掉 log 试一下呢 |
3
no1xsyzy 2021-06-04 13:27:37 +08:00
且不说别的,
95% 请求的响应时间在 100ms 以下,意味着保证最好的单机 qps 等于 CPU 核心数*10 (核心数 * 1s/100ms ) |
4
GopherDaily 2021-06-04 13:33:36 +08:00
@no1xsyzy 时间未必都在 cpu 的
|
5
iyaozhen 2021-06-04 13:57:20 +08:00
没有可比性
我们公司单机是将近 100 核,100 多 GB 内存,万兆网卡的物理机。你要多少 qps 都行 所以压测是个很复杂的事情,需要分析下哪里慢,被压服务是什么并发模型,机器资源利用率多少 |
6
blacksmith 2021-06-04 13:59:15 +08:00
得看具体的应用资源消耗。我们有的应用可以到 300+QPS,有的只有个位数。
|
7
jorneyr 2021-06-04 14:02:22 +08:00
2003 年 15 寸的 MBP,8G 内存,数据从先从 Redis 访问,没有再从 MySQL 获取 (共有 10 万条记录),SpringBoot 应用,QPS 在 16000 左右,测试方式:
1. MBP 连上有线和无限网络 (每个网卡的流量都有限制,开启双网卡进行测试能够更充分的打更多流量) 2. 服务跑在 MBP 上 3. MBP 上使用一个 JMeter,使用无线网络 IP 4. PC 上使用一个 JMeter,使用有线网络 IP |
8
emSaVya 2021-06-04 14:10:51 +08:00
业务太重 我们这单机 qps 就 70
|
9
Jooooooooo 2021-06-04 14:12:28 +08:00
你分析下瓶颈在哪, 一般有 cpu, 网络, 磁盘, 内存, 外部依赖 几个方面.
qps 上不去, 先看哪里到瓶颈了 |
10
CRVV 2021-06-04 14:25:41 +08:00
搜索 web framework benchmark,然后我随便找了一个 https://web-frameworks-benchmark.netlify.app/
qps 从几百到十几万的都有,当然这是 hello world 的测试,没有数据库的。 假设数据库和 redis 和写日志都可以无限扩展并且每个查询只要 2 毫秒,假设每件事情的开销都和处理 hello world 请求一样,那么 qps 大概要除以 4 吧,也就是 qps 从几百到几万。 然后因为 qps 少了,event loop 或者 scheduler 的开销会减少,所以性能也许会再比上面说的数字高一些。 上面说的假设都不见得成立,比如日志很可能要写到硬盘上,而硬盘的性能也天差地别。 很多 ssd 的 iops 都不到 4 万,如果要把日志逐条写到这种硬盘上,qps 就不可能超过 4 万。 另外,树莓派 1 是单机,5 楼说的 100 核也是单机。 所以这个问题根本没有答案。 |
11
xuanbg 2021-06-04 14:35:16 +08:00
我这边接口响应时间基本在 30ms 上下,也就是单核 30QPS 。。。
|
12
no1xsyzy 2021-06-04 15:21:19 +08:00
@GopherDaily 「保证」
更精确地说,qps 的上限的下确界是 CPU 核心数*10 |
13
wellsc 2021-06-04 16:02:24 +08:00 via iPhone
看 io
|
14
byte10 2021-06-04 16:10:36 +08:00 1
|
15
byte10 2021-06-04 16:30:30 +08:00
@Rocketer 楼主已经表达了,很简单的接口。这个问题其实很简单,就是 IO 时间太长了,用 NIO 可以忽略掉时长。实现高并发,不知道楼主用的是啥语言,不过我一猜就知道是 java,python 之类的,就这有这些玩意对 NIO 编程支持菜。java 还没有协程,所以没有成熟的同步框架,异步框架很多都是变成同步写法,响应式还有 vertx 估计大部分人都没学习过。python 的一些框架是可以 支持的,fastapi 好像是 oK,至于 go,nodejs,闭着眼镜写都不至于这样的并发。
|
16
cheng6563 2021-06-04 16:33:30 +08:00
CPU 跑到 100%了吗?网络带宽跑到 100%了吗?没跑到就是你的程序没放开跑。
|
17
lesismal 2021-06-04 17:18:13 +08:00
@byte10 高手,之前的帖子你们聊着聊着就不见了:
https://www.v2ex.com/t/755862 现在 http1.x/tls/websocket 都支持了 本想再支持下 http2.0,但是 http2.0 太渣了,只适合替代 1.x 的接口类业务,但是又不如 ws,所以我放弃 http2.0 了,等以后 http3.x 吧,那时候不再需要 tcp 做 http 载体了,不过目测 2030 年也未必能普及 |
18
lesismal 2021-06-04 17:23:03 +08:00
@no1xsyzy 大部分是 IO 导致的延迟,不能简单按延迟和 CPU 数量计算
4c8t 虚拟机: cat /proc/cpuinfo| grep "physical id" | wc -l 8 ./wrk -t4 -c800 -d10s --latency --script=./echo.lua http://localhost:8080/echo Running 10s test @ http://localhost:8080/echo 4 threads and 800 connections Thread Stats Avg Stdev Max +/- Stdev Latency 4.23ms 3.00ms 73.33ms 82.50% Req/Sec 47.86k 4.49k 57.78k 73.25% Latency Distribution 50% 3.71ms 75% 5.39ms 90% 7.38ms 99% 13.35ms 1906200 requests in 10.04s, 269.05MB read Requests/sec: 189888.68 Transfer/sec: 26.80MB 如果按延迟计算,平均延迟 4.58ms,最多 print(1000/4.58*8) 1746.72489083 但实际跑出来是 Requests/sec: 189888.68 |
19
waibunleung 2021-06-05 02:25:21 +08:00
@byte10 期待视频
|
20
Nillouise OP @byte10 忘了提,确实是 java,数据库连接也是 jdbc bio,访问 redis 应该也是 bio,不过你怎么知道我线程数开小了?用的是 tomcat 默认线程数 200,一个请求响应时间在 200ms 以下,并发应该也支持 1000qps,但实际上并发变高后,延迟就会增加得很多,当然,测试服务器似乎性能很差,可能也就 2 核+2gb 内存。
多谢能出视频讲解,网上都没什么文章提供参考值, @cheng6563 压测的接口速度延迟都变高了,再加并发延迟更高,没什么意义,cpu 倒是没看。 @jorneyr 我的业务流程跟你说的非常相似,也是 spring boot\redis\mysql,这个数字有点超乎我想象。 @xuanbg qps 不是 1000/30=30 这样算的,是一秒可以完成多少并发的查询。 |
21
byte10 2021-06-07 09:52:29 +08:00
@Nillouise jmeter 的话你先设置下 500 个线程 去请求吧,然后 tomcat 设置 500 个线程就好了。应该会有增长。
|
23
Nillouise OP |