【转】构建高性能WEB站点之 吞吐率、吞吐量、TPS、性能测试

内容参考：构建高性能WEB站点.pdf

一、吞吐率

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

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

二、吞吐量

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

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

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

三、事务，TPS(Transaction Per Second)

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

　　TPS:每秒钟系统能够处理事务或交易的数量

　　它是衡量系统处理能力的重要指标。一个 事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

　　TPS包括了：1）用户请求服务器；2）服务器自己的内部处理；3）服务器返回给用户

　　这三个过程，每秒能够完成N个这三个过程，则TPS就为N。

　　点击率可以看作是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个用户向服务器连续进行1000次请求的过程中，任何时刻服务器的网卡缓存区中只有来自该用户的1个请求，而100个用户同时向服务器进行10次请求的过程中，服务器网卡接收缓冲区中最多有100个等待处理的请求，显然这时候服务器的压力更大。

　　经常有人说某个Web服务器能支持多少并发数，除此之外没有任何上下文，这让很多人摸不着头脑，人们常常把并发用户数和吞吐率混淆，他们并不是一回事。通过前面的介绍，我们很清楚，吞吐率是指在一定并发用户数的情况下，服务器处理请求能力的量化体现。

　　如下例子：

　　

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

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

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

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

2、请求等待时间

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

　　首先，假设并发用户数为1，也就是只有一个用户在向服务器源源不断地发送请求，那么每个请求的等待时间也就是它的处理时间，等于总时间除以总请求数，这时用户平均请求等待时间和服务器平均请求处理时间是相同的，这很容易理解。

　　然后，假设并发用户数为100，那么便会有100个用户同时向服务器发送请求，简单地说，这时Web服务器一般会采用多进程或多线程的并发模型，通过多个执行流来同时处理多个并发用户的请求，而多执行流体系的设计原则便是轮流交错使用CPU时间片，所以每个执行流花费的时间都被拉长。对每个用户而言，每个请求的平均等待时间必然增加；而对于服务器而言，如果并发策略得当，每个请求的平均处理时间可能减少。

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

七、总结

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

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

　　以上测试使用硬件为

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

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

转载自《构建高性能WEB站点之 吞吐率、吞吐量、TPS、性能测试》