系统吞吐量基本概念

考考你

如果愿意看下去，不妨试着回答2个问题

• 什么是QPS
• 你所在的系统QPS是多少

犹还记得当时面试时，这2个问题懵逼了。

我们当时做的系统，一个机构管理系统(甚至很多是单机部署的)，没什么大的访问量，也没有准确的数据、工具去统计。

开发一个接口，功能测试完成，就发布上线了，也不会考虑什么QPS。就像下面这样

系统吞吐量

很明显，在现在的稍微大一点的网站中，上面这种单机架构是很快会碰上瓶颈的。然后优化，可能的方向：

• 增加缓存
• 多机集群部署
• 数据库拆分
• 服务拆分

但是，到底我们的系统的性能好坏怎么定义呢，有没有衡量的标准？

直观感觉肯定是是响应变快了，操作流畅了。怎么量化呢？

系统吞吐量：系统的抗压能力，可以理解为系统每秒钟能处理的用户请求数量。

有以下几个参数衡量系统吞吐量：

• QPS
• TPS
• 并发数
• RT

名词解释

QPS：queries per second，每秒钟处理完的请求数量

• 注意这里的Q不是指query-查询，而是指request-请求。所以如果理解为系统每秒处理的查询数量是不对的。
• 必须是系统处理完的请求，而不是能接受的请求，这里必须包含用户的等待时间

处理完具体是指用户发出请求到服务器成功返回响应。对于没有resp的情况，可以理解完server有一个counter，每处理完一个请求+1，1s后的counter就是QPS。

像上面这种情况，假设1s内，1K个请求达到，服务器接受到用户请求之后，全部放入队列里面(put，不消耗时间)，然后再一个个取出任务(get，不消耗时间)，单线程处理(handle，处理1s)，你觉得QPS应该是多少?

肯定是是1/1=1，而不是1000/1=1K。因为系统1s种只能处理完1个请求。

TPS：transactions per second，每秒钟处理完的事务数量。

一般TPS是对整个系统而言的，一个应用系统1S能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求。

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

RT：response time，处理一次请求的平均响应时间

一般TPS用在系统层面，而QPS用在单个接口上面较多。别人可能会问你，你的接口的QPS是多少？

一个例子

上面介绍了概念，下面看一个例子。

假设一个考勤系统，在8点-8点半之间（30分钟），公司的1W个员工要登录打卡，平均打卡完成5分钟。那么系统的对应的qps，并发量，RT是多少呢？

QPS：1000/30*60=5.55，即每秒钟可以完成5.55人打卡。即30分钟内，有1W个请求要处理，平均每秒需要处理5.55个才能处理完成。

RT：5*60=300，即平均响应时间需要300s。即一个请求需要300s才能成功响应

并发量：5.55*300=1666个，即可以同时支持1666人打卡。即最多可以支持1666个人同时打卡，如果再多，有点人就会觉得系统卡了。。。

计算公式

从上面例子可以看到

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

服务接口的QPS

QPS不止衡量应用系统，在分布式系统中，还通常在细粒度层面用来衡量一个接口性能。

比如典型的分布式系统，有3个服务器A，B，C，D，E，F，服务直接通过rpc调用：

可以看到对serviceA的某一个接口X，系统调用链路也很长的，这个时候的QPS可能不止是A系统的性能，而是它依赖的上下游系统都要考虑。

对应分布式系统，必须要做好链路追踪，大公司一般有根据业务定制的，也有开源的框架，比如spring cloud全家桶里面的zipkin，及系统监控（里面可以详细看到每个系统的耗时）。

如果serviceA的X接口QPS为50，另一个接口Y的QPS为40，也不能说明Y的性能比X的差，要结合对应的业务比较才有意义。

QPS需要结合业务功能来看，不能纯粹的比较两个应用的QPS高低。比如A应用或者A服务的最大QPS比B服务高，不能说B服务不行，QPS只有在同一功能或者同一业务服务下才能比较，因为请求处理的平均响应时间是和业务紧密结合的。

压测

对应很多应用，尤其是电商有些秒杀活动的营销活动，对系统的QPS准确预估尤为重要。就是我们一般说的峰值。

比如在很多大促，甚至秒杀场景下，1s内有5w个买家下手，系统必须承载5w的QPS。

假设有20台服务器，每台500个链接。每个请求需要100s处理完成。

那么系统的QPS：20*500/0.1 = 10W，肯定超过5w了，是不是系统的高枕无忧了呢？

那可不一定，在实际的系统运行中，会发现随着请求量的上升，系统的性能不断的下架，一个请求的处理时间可能上升到250s，此时的QPS：20*500/0.25=4W，系统已经超负荷运行了！接着的就是可能CPU飙高，系统崩溃，甚至宕机。

严重的甚至要杀程序员祭天，尼玛。。。。

随着请求量的上升，系统里面的线程开启的越多，上下文切换消耗的时间越来越长，CPU的耗时也随之增加，所以：

如果不进行压测，是很难准确预估的系统的峰值QPS的。

压测的出来的问题，需要解决，可以通过增加机器扩容，或者优化系统。