初级后端的疑惑，如何估算接口 qps，以及 redis 占用多少容量， nginx 能抗多少并发

[waibunleung]

如题，参与公司业务开发中，经常会遇到这样的问题：

1. 这个业务入口会为接口带来多少的 qps 增长？
2. 这个接口能抗住多少 qps ？
3. 这个业务要上缓存的话，预计会带来多少缓存占用？
4. 现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
5. 现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
6. 业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
7. 这个业务的性能瓶颈在哪里？怎么查出来？ 等等

总结的问题就是，大佬们是如何进行业务的容量评估，性能评估，性能排查的？

希望能有大大能逐点解答一下上面的 7 个问题你们在工作中是怎么去分析的，身为菜鸟的我每次遇到这种问题，都头痛半天，然后还是去问大佬怎么怎么弄，但是几次下来也没有总结到套路，都快怀疑自己适不适合干下去了.... 所以想向各位请教下，学习一下大家都是怎么评估和排查问题的，想在这方面有点成长，万分感谢！

看到有这么多人默默收藏了，就说明了其实还是有很多人关心这些问题的，看到这个问题的大佬们，有经验的希望还是能尽量分享下呀~ 求求了

[tachikomachann]

之前看《 java performance definitive guide 》时，作者在第一章说过一句话。大概意思是很多人以为 java 调优就是这样一个按钮，我按下去了调优就完成了。实际上不是的，一个服务的性能瓶颈需要具体问题具体分析，需要结合业务场景，压测结果，profile 工具等一点一点地去分析。然后根据自己需要的性能目标和成本去得出一个折中方案。

lz 可以先看看相关的书籍，学习用一些基本工具（大厂甚至都有一整套自己的工具）和大牛们做性能分析的思路。然后在到自己项目里实践看看。

[whcoding]

可以买阿里云的压测得到你想要的数据.

[waibunleung]

@tachikomachann 我知道肯定会有人说具体问题具体分析，但是问题都是是有分析方向的，就比如你怎么估计一个在服务首页下面增加一个功能入口，新业务增加多少 qps 呢？如果你通过接口监控，知道了这个首页的平均 qps 是 1000，运营告诉你，页面底部的点击率是 25%，那预计带来的 qps 就大约是 250qps，这个 qps 不算高，接口逻辑不复杂的话就能轻松扛过去等等

上面说的 转化率就是一个评估 qps 的方向。
导致性能瓶颈的问题有很多，但是排查瓶颈肯定是有套路的

至于你说学习大牛们做性能分析的思路，提出这个问题的我，就是希望能再这里收获一点思路。

感谢回复啦~

[waibunleung]

@whcoding 公司自建机房

想要问题分析的思路和套路，阿里云并不能告诉我预计业务会增长多少 qps...

[dream4ever]

之前也思考过这个问题，在极客时间买了几门架构设计方面的课，有些课程会讲到这类数据，比如在硬件配置不是瓶颈的情况下，nginx 能扛住多少并发，redis 能扛住多少并发之类的数据，可以看看。

[dream4ever]

而且也会讲如何排查性能瓶颈的方法。

[janxin]

估算都不知道瓶颈在哪怎么估算 orz

所以先做压测找到瓶颈

[jmtung]

1 、性能：压测
2 、redis 内存占用： http://www.redis.cn/redis_memory

[waibunleung]

@dream4ever 请问买的是哪几门课程呢？

[chenqh]

能上 100QPS 都好事了,

[waibunleung]

@jmtung 卧槽，有这个 redis 的预估神器？它估算是怎么估算的？

[Maboroshii]

如果不是那种用户量特别大的服务，就随便搞一个配置，先上线，再观察调整也来得及，就能慢慢积累经验了

[waibunleung]

@Maboroshii 就是那种用户量大的服务

[zed1018]

jmeter 可以压测

[Maboroshii]

@waibunleung #13 压测是一个方案，不过具体还是依赖运营数据和现有数据对比，再考虑配置问题。 总有一个人有经验，任何项目也不是一上线就用户量爆炸的。

[iyaozhen]

这个问题比较复杂。
往往大家只是说做个压测，但压测最难的不是 jmeter 啥的使用，而是压测场景的分析。

这个之前内部写了个文档，需要再重新写个，可能能回答楼主部分问题

[waibunleung]

@Maboroshii 压测确实是一个方案，但是肯定有分析技巧和套路的

[X0ray]

性能评估看压测，
性能排查要做好 metrics 监控，如果有异常了，一拉图标出来很快就能反映出实际情况。

[fantastM]

1 和 2 应该都是先由产品 /运营给出一个预估的用户量，然后通过应用当前的部署情况（比如负载均衡了多少台机器，单台机器的配置，应用运行时的配置，接口的响应时间）估算出接口的 QPS 。
3 sizeof 可以算占用量，不过和具体缓存的数据有关，#8 提到的网站就挺不错。
4 单机的话，可以用 redis-benchmark 跑下看看。
7 压测时候看下各个调用链路里的耗时（或者更细一点的，可以自己打印 log ），还有外部依赖的监控指标等等，出现问题的话，总能看出一些端倪。

[dream4ever]

@waibunleung 《架构实战案例解析》，《许式伟的架构课》，《从 0 开始学架构》，但是上面说的内容具体在哪个专栏里现在印象不深了。

[waibunleung]

@iyaozhen 大佬可以简单回答一下，然后再把写好的文档分享一下~

[waibunleung]

@fantastM 太棒了，就是需要类似这样的回复！还有请问下，类似于 4k qps mysql 能不能扛得住，会不会报警这种问题，要怎么思考呢？

[liudaolunhuibl]

事实上你接口能承受住多少 QPS 大部分是你的服务器和中间件决定的，你的代码里能决定的只是 GC 频率、CPU 占用率、数据库链接等等

[liudaolunhuibl]

对了推荐一个 redis 的客户端——Another Redis Desktop Manager，github 开源的， 是一个 MIT 的国人大佬开发的，非常非常好用

[Jooooooooo]

靠压测是个工作中实践时候的正确答案

但是面试或者领导问你这个问题显然不能这么答

可以考虑从线程池模型，io 耗时，业务敏感度等等几个方面去回答

[waibunleung]

@liudaolunhuibl 请移步推广节点

[waibunleung]

@Jooooooooo 能否举些例子呢？

[fantastM]

#22 先确定一些「能不能扛得住」的指标吧，不同场景对系统正常运行的指标是不同的（例如后台的统计 SQL 和用户的实时查询 SQL 对延迟的要求），然后跑基准测试看看。MySQL 的话，你可以看看《高性能 MySQL 》的第二章，或者搜关键字 mysql+benchmark

[waibunleung]

@fantastM 好的，感谢大佬！

[StrongNoodles]

压测，虽然和实际还是有出入，但是已经很有参考价值了

[qwerthhusn]

@liudaolunhuibl 不好用，字体很丑，Win10 缩放也有问题，俺推荐 RedisInsight，也是免费

[SorcererXW]

性能瓶颈可以使用 apm 、jaeger 这种 tracer，加上压测，看看整个链路上的性能瓶颈在哪里

[waibunleung]

@SorcererXW 那接口 qps 预估呢？

[fengpan567]

jmeter 自己压一波

[Rocketer]

不同的应用类型，QPS 峰值分布也不一样。我们（电商）一般会把一天的访问量平均分到 10 小时里去，然后按平均值的 10 倍配置负载能力。比如一天 100 万的访问量，那么 QPS 能撑住 1000000/36000*10=278 就可以了

[LeeReamond]

1 和 6 不是开发考虑的问题，2 和 4 的大概值估算是开发的基本功，写代码时候就知道大概是多少了，想知道具体值可以压测，5 的网关性能瓶颈几乎没见哪个业务遇到过，业务量大到这个份上还搞不清瓶颈在哪里比较玄学。7 多学习

[LeeReamond]

收藏数多大概是因为 LZ 问题问的不错，以后遇到初级开发可以让他挨个点考教

[luwill]

简单会答一下前几个问题。这 7 个问题应该能写一篇文章。
>这个业务入口会为接口带来多少的 qps 增长？
这个可以根据之前的相似业务来预测。主要是考虑业务在前端的露出位置，或者是替代其他业务的量。
或者套用一些 UG 策略公式，比如你们业务的页面转换率漏斗来计算。
>这个接口能抗住多少 qps ？
需要压测，估算都是不准的，可以使用单机压测，多机压测，真实业务环境压测，全链路压测
压测很多时候是帮你找到薄弱环节，整个业务的最大 qps 往往在短板上，比如 数据库，下游服务上。
>这个业务要上缓存的话，预计会带来多少缓存占用？
这个只能计算最大值，很难计算实际使用，毕竟缓存都有过期。不同的过期时间需要的空间大小不同。、
最简单的算法，缓存最大值 = 活跃人群 x 单个用户占用缓存最大值。

[tairan2006]

直接压

[neptuno]

花多少钱，投多少广告，能带来多少点击，这些数据都能帮助你预估 qps，然后进行压测。扛不住了，企业微信预警，先加机器，然后再优化

[waibunleung]

@Rocketer 就是想知道这种评估方法是，这感觉只回答到第 2 点，缓存之类的要怎么估算呢？希望能再给些指点

[waibunleung]

@LeeReamond 2，4 是基本功，那想问一下有什么方向去估算呢？能否给些方向说明一下？感谢~

[LeeReamond]

@waibunleung 我觉得你这样问没什么意思，问也问不出什么。我的意思是作为开发，常用的工具链最起码要搞熟，一般一个网络服务中有若干个子服务，比如网关、业务、缓存、（虚拟的）数据层，这些不用挨个罗列是所有人都知道的事，搞熟的意思最起码你要知道每个框架作为工具的负载能力，你比如你在调数据库业务的时候，你知道表有多大，什么储存方式，业务如何索引，集群的负载增幅是多少，那你应该能估算出单节点大概的时间范围，其他环节同理，遇到特殊情况完全估算不出的那不妨测一测。我的意思是这么简单的道理，为什么要问呢。

[waibunleung]

@LeeReamond 就你说的这个场景，「你比如你在调数据库业务的时候，你知道表有多大，什么储存方式，业务如何索引，集群的负载增幅是多少，那你应该能估算出单节点大概的时间范围」 比如数据库是 mysql，我知道表有 3000w 行，innodb 存储，索引覆盖了要查询的字段，集群的负载增幅我并没有理解到你想表达的是什么意思，当我不知道，那估算单节点的时间范围是怎么估算的呢？

[waibunleung]

@LeeReamond 也不是这样问没有意思，主要是你的回答我也没从里面看出什么经验总结来....你所说的基本功，我认同这一点，那既然是基本功，就肯定可以总结出一两点套路的

[LeeReamond]

@waibunleung 你当然无法从我的回答总结出经验，纸上谈兵谈不出兵，你跑一跑当然就有经验了。比如你这个例子里，正常开发对于不同数据库的负载能力心里有个量级，比如如果表内有 30 万行，大多数情况下我不会太在意搜索性能，而 3000 万行对于 mysql 单表来说属于稍大的量级，需要给予一些关注，同理如果是 oracle 那又是另一种情况，我是这个意思。具体说到存储的话，单表不说明问题，具体与分区分表和你的业务高度绑定，当然只有你自己知道多快，不过你写 sql 语句的时候通过估算复杂度可以估算出一个大概的量级，比如 a 语句会低延迟返回，b 语句需要花费若干秒，c 语句需要若干分钟等等，按数量级估算当然是开发的基本功。我说集群负载能力的意思是根据你集群方式的不同负载能力的增幅当然不是线性的。

同理关系型数据库是这样，对业务中其他环节你都应该有这样的估算，比如上述所谓 a 语句低延迟返回，这也是少数有可能造成其他环节瓶颈的业务，就需要更量化的分析。

[waibunleung]

@LeeReamond 我觉得问题就在于，「正常开发对于不同数据库的负载能力心里有个量级」 这个点不好把握，30w 行内不会在意性能，3000 万行予以关注可以理解，但是 3000 万行的单表，会引起我两个问题，
1.数据量一直增长到 3000 的过程中，查询请求也一路增长，我会一直担心数据库顶不住，因为虽然我能预估一个查询多久能返回，但是没法预估这张表能抗得住多少并发请求，就是我没有办法给出 「这种情况下，如果你再多开一个业务入口，流量上涨，更多的流量到达数据库之后，数据库会扛不住的」的结论给到运营或者老大
2. 「正常开发对于不同数据库的负载能力心里有个量级」这个量级是怎么得来的？或者说你是怎么知道 mysql 什么机器配置下能抗多少请求的呢？
还望再指点一二

[LeeReamond]

@waibunleung 不知道你写了这么多有什么好指点的，跟你聊真是浪费时间，多试就完事了

[waitingChou]

这个业务入口会为接口带来多少的 qps 增长？
===== 这个基于原有页面的曝光，和类似入口的点击率来估算，实在不放心可以灰度
这个接口能抗住多少 qps ？
===== 压测
这个业务要上缓存的话，预计会带来多少缓存占用？
===== qps 都有了，可以估一个占用上限出来。 当然，有些数据是公用的，只要缓存一份，有些用户独占的，看你访问用户数，再结合你的缓存过期时间来估算。比如缓存时间一天，一天内有 1 万用户访问这个接口，每个用户需要缓存数据量。
现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
===== 看 redis 缓存的数据类型和数据大小，配合历史的 redis 监控图标数据来做分析估算，比如流量增加一半，假设 redis 线性增加会到一个什么量级。
现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
=====这个没多少经验，暂不做回答。
业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
=====正常来说思路还是压测，但是如果考虑这么多，那为了真实需要在生产压测，风险比较高。
这个业务的性能瓶颈在哪里？怎么查出来？ 等等
===== 我个人两种思路，第一种直接看代码，分析这段代码有哪些外部调用 /依赖，然后再从中挑出风险最高的部分。 另外一种压测配合火焰图或者 benchmark 类工具实际运行分析。

[waibunleung]

@waitingChou 很好，给了不少方向！感谢感谢

[waibunleung]

@waitingChou 就是想要这样形式的回答，实在符合我的期待

[awanganddong]

这是架构师之路的大概介绍。
https://cloud.tencent.com/developer/article/1553360

技术层面就是对现有的组建进行性能分析。
比如我们语言是 php

一台服务器 256 个 php-fpm 进程， 每个 fpm 进程 1s 支持 3 个响应。那就是 256 * 3 就是单台 qps 上限。再乘以总服务器数。这个就是单台服务器能承载的 qps

还有就是对 mysql 的压测。mysql 理论上读+缓存。 写的话最好压测下 mysql 的极限。比如使用 mysql 压力工具。或者使用 update 手动压测。从 mysql 开始变慢算起。得到一个 mysql 写的 qps 。 读的话，一般从 mysql 连接数上入手。 一般 mysql 支持 2000-5000 左右的链接。 每次请求就打开一个 mysql 链接。 这块我现在还不太明晰，正实践中。