吞吐率、吞吐量、TPS、性能测试，纸上不谈兵

https://ruby-china.org/topics/26221

一、吞吐率

我们一般使用单位时间内服务器处理的请求数来描述其并发处理能力。称之为吞吐率（Throughput），单位是 “req/s”。吞吐率特指 Web 服务器单位时间内处理的请求数。

另一种描述，吞吐率是，单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标。通常情况下，吞吐率 “字节数/秒” 来衡量。当然你也可以用 “请求数/秒” 和 “页面数/秒” 来衡量。其实不管一个请求还是一个页面，它的本质都是在网络上传输的数据，那么用来表述数据的单位就是字节数。

二、吞吐量

吞吐量，是指在一次性能测试过程中网络上传输的数据量的总和。

　　对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产 10W 吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉 2 吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

　　提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出 10 吨水；10 个水龙头开 1 秒钟，流出 0.1 吨水。当然是一个水龙头的吞吐量大。你能说 1 个水龙头的出水能力是 10 个水龙头的强？所以，我们要加单位时间，看谁 1 秒钟的出水量大。这就是吞吐率。

三、事务，TPS(Transaction Per second)

就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS

每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

点击率可以看做是 TPS 的一种特定情况。点击率更能体现用户端对服务器的压力。TPS 更能体现服务器对客户请求的处理能力。

每秒钟用户向 web 服务器提交的 HTTP 请求数。这个指标是 web 应用特有的一个指标；web 应用是 “请求 - 响应” 模式，用户发一个申请，服务器就要处理一次，所以点击是 web 应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和 TPS 就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次 “单击” 操作，因为一次 “单击” 操作中，客户端可能向服务器发现多个 HTTP 请求。

四、吞吐量、吞吐率的意义

• 吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在的位置
• 80% 系统的性能瓶颈都是由吞吐量制约
• 并发用户和吞吐量瓶颈之间存在一定的关联
• 通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身 4 个环节确定系统的性能瓶颈。

五、吞吐率和压力测试

单从定义来看，吞吐率描述了服务器在实际运行期间单位时间内处理的请求数，然而，我们更加关心的是服务器并发处理能力的上限，也就是单位时间内服务器能够处理的最大请求数，即最大吞吐率。

所以我们普遍使用 “压力测试” 的方法，通过模拟足够多数目的并发用户，分别持续发送一定的 HTTP 请求，并统计测试持续的总时间，计算出基于这种 “压力” 下的吞吐率，即为一个平均计算值

！！注意

• 在 Web 服务器的实际工作中，其处理的 HTTP 请求通常包括对很多不同资源的请求，也就是请求不同的 URL， 比如这些请求有的是获取图片，有的是获取动态内容，显然服务器处理这些请求所花费的时间各不相同，而这些请求的不同时间组成比例又是不确定的。这就是实际情况下的吞吐率。

• 所以，我们 对于同一个特定有代表性的请求进行压力测试，然后对多个请求的吞吐率按照比例计算加权平均值。

• Web 服务器并发能力强弱的关键便是在于如何计算针对不同的请求性质来设计最优并发策略。在一定程度上使得 Web 服务器的性能无法充分发挥，这很容易理解，就像银行对不同业务设立不同的窗口一样，这些窗口的服务员分别熟悉自己的窗口业务。可以未不同的客户分别快速办理业务，但是如果让这些窗口都可以办理所有业务，也就是客户可以去任何窗口办理任何业务，那会是怎么样呢？没有几个银行业务员会对所有业务都轻车熟路，这样势必会影响到整体的业务办理速度。

六、压力测试的前提

吞吐率性能测试的前提

• 并发用户数
• 总请求数
• 请求资源描述

压力测试的描述一般包括两个部分，即并发用户数和总请求数，也就是模拟多少用户同时向服务器发送多少请求。

请求性质则是对请求的 URL 所代表的资源的描述，比如 1KB 大小的静态文件，或者包含 10 次数据库查询的动态内容等。

1、 并发用户数

并发用户数就是指在某一时刻同时向服务器发送请求的用户总数。

假如 100 个用户同时向服务器分别进行 10 次请求，与 1 个用户向服务器连续进行 1000 次请求。两个的效果一样么？

一个用户向服务器连续进行 1000 次请求的过程中，任何时刻服务器的网卡接受缓存区中只有来自该用户的 1 个请求，而 100 个用户同时向服务器分别进行 10 次请求的过程中，服务器网卡接收缓冲区中最多有 100 个等待处理的请求，显然这时候服务器的压力更大。

经常有人说某个 Web 服务器能支持多少并发数，除此之外没有任何上下文，这让很多人摸不着头脑，人们常常把并发用户数和吞吐率混淆，他们并不是一回事。

一个服务器最多支持多少并发用户数呢？

我们可以说，这个柜台支持的最大并发数为 10，因为恰好在这个并发数下，柜台业务开展的非常成功。顾客们都对服务时间非常满意，而此时代表业务办理次数的柜台吞吐率也比较高，商场和顾客们实现双赢。

可见，通常所讲的最大并发数是有一定利益前提的，那就是服务器和用户双方所期待的最大收益，服务器希望支持高并发数及高吞吐率，而用户不管那么多，只希望等待较少的时间，或者得到更快的下载速度。

所以得出最大并发数的意义，在于了解服务器的承载能力，并且结合用户规模考虑适当的扩展方案。

对于同一域名下 URL 的并发下载数是有最大限制的，具体限制视浏览器的不同而不同。 一个真实的用户可能会给服务器带来两个或更多的并发用户的压力，一些高明的用户还可以通过一些方法来修改浏览器的并发数限制。

2、请求等待时间

• 用户平均请求等待时间
• 服务器平均请求处理时间

用户平均请求等待时间主要用户衡量服务器在一定并发用户数的情况下，对于单个用户的服务质量 服务器平均请求处理时间与前者相比，则用户衡量服务器的整体服务质量，它其实就是吞吐率的倒数。

七、压力测试

Apache 附带的 ab，ab 可以直接在 web 服务器本地发起测试请求。

1、吞吐率随并发用户数变化的曲线图

2、服务器平均请求处理时间随并发用户数变化的曲线图
当并发用户数超过 150 之后，请求的平均等待时间大幅度增加，当并发用户达到 200 后，等待时间开始急剧增加。

3、用户平均请求等待时间随并发用户数变化的曲线图

八、总结

针对，吞吐量，吞吐率，TPS 的测试，都需要指明单位时间。

以上测试忽略服务器硬件配置，所以性能测试结果也不侧重于它的绝对值意义，我们的目的是探讨如何测量性能以及如何根据不同的场景来优化性能。

以上测试使用硬件为

CPU： Intel(R) Xeon(R) CPU 1.60GHz 内存：4GB 硬盘转速： 15kr/min

以上几个指标的测试，主要是为了提升服务器的处理效率，为构建高可用的 Web 站点做准备。

影响 吞吐量，吞吐率，TPS 指标的因素，除了服务器的硬件配置，就剩下并发策略了。

简单地说，并发策略的设计就是在服务器同时处理较多请求的时候，如何合理协调并充分利用 CPU 计算和 I/O 请求，使其在较大并发用户数的情况下提供较高的吞吐率

并不存在一个对所有性质的请求都高效的并发策略

参考：

我的简书
性能测试知多少 -- 吞吐量
构建高性能 Web 站点