【性能测试系列二】性能指标：四个基本指标

一、基本性能指标

序号	指标	含义	含义
1	并发用户数		在某一时间点，服务器正在处理的请求数
2	响应时间	RT	服务响应一次请求的花费的时间
3	吞吐率	（TPS/RPS）	系统每秒能处理的请求数
4	错误率	FR	指系统在负载情况下，失败交易的概率

1、并发用户数：~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

并发用户数分为两个层面
（1）业务层：实际使用系统的用户总数。
（2）后端服务器层：“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

举例来说：
A：工程师经常说：1秒并发2000，其实他指的是QPS=2000。

B：而一个网站管理员说：我们并发1000人，其实指的最大在线人数1000人。在线人数1000人并不意味每个人都同一时间在跟服务器做交互，因此服务器的并发数并未到1000.

C：运维人员说：我设置的tomcat的并发数500，他指的是这个tomcat最多可以调用500个线程同时接受请求。也就是同一时间服务器能达到的最大并发数数是500，但是受限于CPU、OS等其他原因，并发数在实际中达不到这个数值。

D：性能测试人员说：我在LR中设置了并发数3000，指的是他在测试工具中设置3000个并发模拟用户，只是理论上在单位时间内最多会有3000个的模拟请求到服务器上。但是从客户端角度出发，客户端有可能因为CPU、OS、等待时间等等限制，并不能达到此压力。即使客户端达到了此压力，但是从服务器的角度出发，会有排队机制以及部分请求异常溢出，并不能说服务器的并发就到了3000。

因此性能测试中的并发数指的是一个测试出来的结果计算值

2、响应时间：~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

响应时间是服务响应一次请求的花费的时间。在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间 。还有需要经常考虑的最大/最小响应时间

（1）平均响应时间：就是完成请求花费的总时间/完成的请求总数
但是平均响应时间有一点不靠谱，因为系统的运行并不是平稳平滑的，如果某几个请求的时间超短或者超长就会导致平均数偏离很多。可以参考读新闻的平均工资、平均房价等，你就知道为什么不那么靠谱了。因此有时候我们会用中位数响应时间。

（2）中位数的意就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫做这组数据的中位数
最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的请求都小于某个值，TP90表示90%的请求小于某个时间

行业参考标准：
不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
①互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
②金融企业：1秒以下为佳，部分复杂业务3秒以下。
③保险企业：3秒以下为佳。
④制造业：5秒以下为佳。
⑤时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。

3、吞吐量：~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

吞吐量是每秒钟系统处理的请求数，是最能直接体现软件系统负载承受能力的指标

理解：
所有对吞吐量的讨论都必须以“单位时间”作为基本前提。其实，我认为 把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率=吞吐量/单位时间。但既然国内很多资料已经翻译为了“吞吐量”，所以通常情况下我们不会刻意去区分吞吐量和吞吐率，统称为吞吐 量。

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

这里需要特别注意的是：
虽说吞吐量可以反映服务器承受负载的情况，但在不同并发用户数的场景下， 即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也会相差甚远。

4、错误率：~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

错误率＝(失败交易数/交易总数)*100%
行业参考标准：
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%

三、最大并发量的应用

系统的最大并发量只是一个技术上的理论值，往往在技术团队内吹吹牛，而鲜有业务同学感兴趣。在你对自己1000个最大并发量感到沾沾自喜的时候，客户质问：“你说的1000并发到底能承载多少个用户呀？”。这时你往往懵逼了，这时你往往要问客户一句：”你问的是注册用户，还是同时在线用户？“。

现实的情况是单个功能模块的QPS及最大并发数，往往很难估算出全站的业务含义上的用户量，现实生活比计算机机房模拟的环境要复杂的多，需要考虑网络环境、用户对各个功能点的使用率、用户的操作习惯行为等，即使你使用LR等复杂的测试模拟工具，对不同的功能模块进行了综合的测试，往往也只能得出一个估算的值，而且你往往遇到的最大的问题是你没有那么强的扮演成千上万模拟客户端的测试机，即使你有，你往往又没有那么宽的带宽，在压力上去之后，网络首先成为了瓶颈