V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Nillouise
V2EX  ›  程序员

单机的 qps 普遍是多少?网上基本都没搜到什么资料说明

  •  1
     
  •   Nillouise · 2021-06-04 13:17:57 +08:00 · 7478 次点击
    这是一个创建于 1266 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我自己用 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,感觉问题真是大。。。。

    24 条回复    2021-06-11 16:44:41 +08:00
    Rocketer
        1
    Rocketer  
       2021-06-04 13:24:11 +08:00 via iPhone
    逻辑不同,有什么可比的呢?

    我司的核心服务只有 30QPS,三台服务器负载均衡支撑百万日访问量很稳
    Vegetable
        2
    Vegetable  
       2021-06-04 13:24:19 +08:00
    我刚写代码第一年用 django 写的服务,请求第三方服务+数据库操作,都不只 200qps 。

    你这个情况太模糊,「打 log 」是打印 log 吗?打印到控制台是有可能影响性能的,关掉 log 试一下呢
    no1xsyzy
        3
    no1xsyzy  
       2021-06-04 13:27:37 +08:00
    且不说别的,
    95% 请求的响应时间在 100ms 以下,意味着保证最好的单机 qps 等于 CPU 核心数*10 (核心数 * 1s/100ms )
    GopherDaily
        4
    GopherDaily  
       2021-06-04 13:33:36 +08:00
    @no1xsyzy 时间未必都在 cpu 的
    iyaozhen
        5
    iyaozhen  
       2021-06-04 13:57:20 +08:00
    没有可比性

    我们公司单机是将近 100 核,100 多 GB 内存,万兆网卡的物理机。你要多少 qps 都行

    所以压测是个很复杂的事情,需要分析下哪里慢,被压服务是什么并发模型,机器资源利用率多少
    blacksmith
        6
    blacksmith  
       2021-06-04 13:59:15 +08:00
    得看具体的应用资源消耗。我们有的应用可以到 300+QPS,有的只有个位数。
    jorneyr
        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
    emSaVya
        8
    emSaVya  
       2021-06-04 14:10:51 +08:00
    业务太重 我们这单机 qps 就 70
    Jooooooooo
        9
    Jooooooooo  
       2021-06-04 14:12:28 +08:00
    你分析下瓶颈在哪, 一般有 cpu, 网络, 磁盘, 内存, 外部依赖 几个方面.

    qps 上不去, 先看哪里到瓶颈了
    CRVV
        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 核也是单机。

    所以这个问题根本没有答案。
    xuanbg
        11
    xuanbg  
       2021-06-04 14:35:16 +08:00
    我这边接口响应时间基本在 30ms 上下,也就是单核 30QPS 。。。
    no1xsyzy
        12
    no1xsyzy  
       2021-06-04 15:21:19 +08:00
    @GopherDaily 「保证」
    更精确地说,qps 的上限的下确界是 CPU 核心数*10
    wellsc
        13
    wellsc  
       2021-06-04 16:02:24 +08:00 via iPhone
    看 io
    byte10
        14
    byte10  
       2021-06-04 16:10:36 +08:00   ❤️ 1
    楼主,我下次出一个视频给你讲讲吧。如果你用 NIO,就你那点业务,四核 cpu 随便破万,如果用 BIO,那么可能要设置几千个线程。第二个如果是 java 项目,那么要先跑一万次接口,这样可以触发 jit,后面的性能会显著提高。
    其实关于测试 http 接口,其实非常有意思,但是很多人不懂。在 NIO 的服务中,http 连接数也是一个非常大的变量的,但是很多人不懂。我得出个教程教下大家。

    @no1xsyzy 你讲的不对。你这公式都套错了。。。下次要多学习。
    @iyaozhen 主要还是跟并发模型有关系,楼主线程太少了,随便设置 500 个就都不值这点并发。
    byte10
        15
    byte10  
       2021-06-04 16:30:30 +08:00
    @Rocketer 楼主已经表达了,很简单的接口。这个问题其实很简单,就是 IO 时间太长了,用 NIO 可以忽略掉时长。实现高并发,不知道楼主用的是啥语言,不过我一猜就知道是 java,python 之类的,就这有这些玩意对 NIO 编程支持菜。java 还没有协程,所以没有成熟的同步框架,异步框架很多都是变成同步写法,响应式还有 vertx 估计大部分人都没学习过。python 的一些框架是可以 支持的,fastapi 好像是 oK,至于 go,nodejs,闭着眼镜写都不至于这样的并发。
    cheng6563
        16
    cheng6563  
       2021-06-04 16:33:30 +08:00
    CPU 跑到 100%了吗?网络带宽跑到 100%了吗?没跑到就是你的程序没放开跑。
    lesismal
        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 年也未必能普及
    lesismal
        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
    waibunleung
        19
    waibunleung  
       2021-06-05 02:25:21 +08:00
    @byte10 期待视频
    Nillouise
        20
    Nillouise  
    OP
       2021-06-06 02:34:33 +08:00
    @byte10 忘了提,确实是 java,数据库连接也是 jdbc bio,访问 redis 应该也是 bio,不过你怎么知道我线程数开小了?用的是 tomcat 默认线程数 200,一个请求响应时间在 200ms 以下,并发应该也支持 1000qps,但实际上并发变高后,延迟就会增加得很多,当然,测试服务器似乎性能很差,可能也就 2 核+2gb 内存。

    多谢能出视频讲解,网上都没什么文章提供参考值,

    @cheng6563 压测的接口速度延迟都变高了,再加并发延迟更高,没什么意义,cpu 倒是没看。

    @jorneyr 我的业务流程跟你说的非常相似,也是 spring boot\redis\mysql,这个数字有点超乎我想象。

    @xuanbg qps 不是 1000/30=30 这样算的,是一秒可以完成多少并发的查询。
    byte10
        21
    byte10  
       2021-06-07 09:52:29 +08:00
    @Nillouise jmeter 的话你先设置下 500 个线程 去请求吧,然后 tomcat 设置 500 个线程就好了。应该会有增长。
    byte10
        22
    byte10  
       2021-06-07 09:53:56 +08:00
    @Nillouise 另外你的 redis 和数据库 应该是服务是内网吧,如果这都不是内网的话,那么就比较麻烦了。。
    Nillouise
        23
    Nillouise  
    OP
       2021-06-07 16:37:56 +08:00
    @byte10 redis 和数据库跟应用服务器是同一个内网,客户端倒不是,不过我都离职了,在家狂玩,不干这么麻烦的事情了,发贴只是想问问答案。

    大佬你视频还有计划出吗?
    byte10
        24
    byte10  
       2021-06-11 16:44:41 +08:00
    @Nillouise 等我消息,放假我搞一个吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5439 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 03:21 · PVG 11:21 · LAX 19:21 · JFK 22:21
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.