专项研究-系统容量评估

最新推荐文章于 2021-10-24 17:23:07 发布

能源恒观

最新推荐文章于 2021-10-24 17:23:07 发布

阅读量1.3k

点赞数

分类专栏：架构系列

原文链接：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959542&idx=1&sn=2494bbea9a855e0e1c3ccd6d2562a600&scene=21#wechat_redirect

版权

架构系列专栏收录该内容

18 篇文章 0 订阅

订阅专栏

1. 需求缘起
- 1.1QPS/TPS/并发量/系统吞吐量的概念
- 1.2系统吞度量要素
- 1.3系统吞吐量评估
2.容量评估的步骤与方法
3.总结

1. 需求缘起

互联网公司，这样的场景是否似曾相识：

场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题：

（1）机器能抗住么？

（2）如果扛不住，需要加多少台机器？

场景二：系统设计阶段，技术老大杀过来，又问了两个问题：

（1）数据库需要分库么？

（2）如果需要分库，需要分几个库？

技术上来说，这些都是系统容量预估的问题，容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，今天分享的内容，就以【并发量】为例，看看如何回答好这两个问题

1.1QPS/TPS/并发量/系统吞吐量的概念

QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。

吞吐量: 这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数；

TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。

并发量：系统能同时处理的请求数

RT：响应时间，处理一次请求所需要的平均处理时间

计算关系：

QPS = 并发量 / 平均响应时间

并发量 = QPS * 平均响应时间

1.1系统吞度量要素

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（TPS）：每秒钟request/事务数量

并发数： 系统同时处理的request/事务数

响应时间： 一般取平均响应时间

（很多人经常会把并发数和TPS理解混淆）

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降

1.2系统吞吐量评估

我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。

通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

通常的技术方法：

1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）

2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。

淘宝流量图：

在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小

软件性能的关注点

对一个软件做性能测试时需要关注那些性能呢？

我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次，我们站在管理员的角度考虑需要关注的性能点。

1、响应时间
2、服务器资源使用情况是否合理
3、应用服务器和数据库资源使用是否合理
4、系统能否实现扩展
5、系统最多支持多少用户访问、系统最大业务处理量是多少
6、系统性能可能存在的瓶颈在哪里
7、更换那些设备可以提高性能
8、系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1、架构设计是否合理
2、数据库设计是否合理
3、代码是否存在性能方面的问题
4、系统中是否有不合理的内存使用方式
5、系统中是否存在不合理的线程同步方式
6、系统中是否存在不合理的资源竞争

那么站在性能测试工程师的角度，我们要关注什么呢？

一句话，我们要关注以上所有的性能点。

2. 容量评估的步骤与方法

【步骤一：评估总访问量】

如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？

答案是：询问业务方，询问运营同学，询问产品同学，看对运营活动或者产品上线后的预期是什么。

举例：58要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，求push落地页系统的总访问量？

回答：5000w*10% = 500w

【步骤二：评估平均访问量QPS】

如何知道平均访问量QPS？

答案是：有了总量，除以总时间即可，如果按照天评估，一天按照4w秒计算。

举例1：push落地页系统30分钟的总访问量是500w，求平均访问量QPS

回答：500w/(30*60) = 2778，大概3000QPS

举例2：主站首页估计日均pv 8000w，求平均访问QPS

回答：一天按照4w秒算，8000w/4w=2000，大概2000QPS

提问：为什么一天按照4w秒计算？

回答：一天共24小时*60分钟*60秒=8w秒，一般假设所有请求都发生在白天，所以一般来说一天只按照4w秒评估

【步骤三：评估高峰QPS】

系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？

答案是：根据业务特性，通过业务访问曲线评估

举例：日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？

回答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。

说明：有一些业务例如“秒杀业务”比较难画出业务访问趋势图，这类业务的容量评估不在此列。

【步骤四：评估系统、单机极限QPS】

如何评估一个业务，一个服务单机能的极限QPS呢？

答案是：压力测试

在一个服务上线前，一般来说是需要进行压力测试的（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：

1）访问端是APP

2）运营活动H5落地页是一个web站点

3）H5落地页由缓存cache、数据库db中的数据拼装而成

通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。一般来说，线上系统是不会跑满到极限的，打个8折，单机线上允许跑到QPS1000。

【步骤五：根据线上冗余度回答两个问题】

好了，上述步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，就能自信自如的回答技术老大提出的问题了：

（1）机器能抗住么？ -> 峰值5000，单机1000，线上2台，扛不住

（2）如果扛不住，需要加多少台机器？ -> 需要额外3台，提前预留1台更好，给4台更稳

除了并发量的容量预估，数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤