3

如何评估、预测系统的QPS

 1 year ago
source link: https://cloud.tencent.com/developer/article/1553360
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

[TOC]

如何评估、预测系统的QPS

容量评估按照5倍冗余计算

系统架构设计背景

当我们在设计一套系统的时候,我们要考虑好系统的架构设计、模块划分、技术方案选型、还有系统性能如能够承受的QPS。当我们线上系统能够支撑10W QPS的时候,我们要考虑100W QPS的架构优化、当我们系统能够支撑100W的时候,我们要思考1000W的架构优化和改进。同时,经验告诉我们,从10W到100W再到1000W一定不是理所当然的线性增长。

为啥要提前预估线上的最大QPS,因为这样我们才能做到白盒化,才能做到心中有数,才能提前有一定的方案,但是这个方案不一定要马上实施,作为技术人员,方案是一定需要有的,什么时候实施,如何时候是另外一回事。

本文就如何评估、预测我们系统的QPS做一些经验输出,不足之处望大佬们指正~

评估案例和方案

为啥要进行评估?因为不同的QPS,所带来的挑战是不同的,架构设计也是不一样的

如何评估系统的QPS

如何评估系统的QPS,指的是我们的系统支撑的业务场景需要满足的一个最大承压,对于一个新项目而言,一般来说,有这样几个方式:

  1. 产品和运营人员告诉你,我们这个系统上线,日活达到多少、同时在线达到多少、总用户将会有多少等等,这个是产品和运营对这个新项目的预估
    • 这个是一个参考数据,不能全信也不可不信
  2. 凭借自身已有的经验进行预估,如一个视频聊天的产品的预估、如一个社交产品的预估、如一个微博系统的预估等等。

社交、视频聊天的预估

对于视频聊天,我们可以这样预估QPS:

  1. 预估平均每个用户每天30次视频匹配、 15次视频聊天
  2. 预估每个用户每天30分钟视频时间,峰值为平均QPS的3-4倍,一天时间24h

不同日活的不同数据:

  • 10w*30分钟 * 4 / 24h = 0.83w QPS
  • 100W*30分钟 * 4 / 24h = 8.3w QPS

目前是预估30分钟,但是后面爆款后,这个时长可能变化很大,需要预留一定的流量,并且百万日活,并不是仅仅是100w,300w-400w内,都算百万日活,因此,在此基础上,还要再有3-4倍的量。

Feed系统的预估

对于Feed这样的系统(如微博),我们可以预估一下,全量用户每天总共会发送1000W条Feed,那么Feed子系统一天就会产生1000W条消息,同时,我们预估每条Feed平均有10个用户会去查看,也就是要读取这条消息,因此读取消息就是1亿次。

这也是一天的总量,那么QPS如何算呢?

  • 写:1000W / 24 h = 115.7 QPS
  • 读:115.7 * 10 = 1157 QPS

按照上面的推论,峰值为平均QPS的3-4倍,那么实际的QPS应该是:

  • 写:1000W / 24 h * 4 = 463 QPS
  • 读:115.7 * 10 * 4 = 4630 QPS

同时为了应对高峰,和后续的增长,我们的QPS肯定要在现有基础上再进行一些扩充,一般还是3-4倍余量。因此,最终我们预估:

  • 写:1000W / 24 h * 4 * 4 = 1852 QPS
  • 读:115.7 * 10 * 4 * 4 = 18520 QPS

这里的3-4倍不是一定的,但是是根据实际经验的一个参考值,不同的业务会有不同的倍数。

如何预测系统的QPS

在预测系统的QPS前,我们需要有一些已知的经验型数据,如日志QPS在6-10w、 RPC的QPS在 10W ,Redis的QPS是8-10w,MySQL大致6k-1W。以上是大体范围,不同机器不同配置有不同结果。

抛开其他的不谈,我们需要看看,我们一次请求调用,有多少次写日志、多少次读写底层资源、多少次RPC调用,然后取其中最低的个值,这是我们预测系统能够达到的最大值。

然而,我们压测的目的在于验证我们的猜测,看看我们实际系统和预测的有多少差别。这就是为什么有经验的人只要你告诉他你的系统架构设计,他就能预估你的系统最大能承受的QPS是多少的原因。

在实际应用中,我按照此种方式去预测和压测,发现压测的值和预测的值,相差比较小,当然压测数据一定是小于预测数据的。这就说明系统设计的还算ok。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK