系统并发性能指标与测试工具介绍

一、性能指标介绍

1.1 并发用户数

1.2 TPS(每秒事务数)

1.3 QPS（每秒查询率）

1.4 TPS与QPS的区别与关系

1.4.1 区别

1.4.2 关系

1.5 响应时间（RT）

二、指标评估

2.1 背景

2.2 获取性能指标

2.3 性能指标计算/统计方式

2.3.1 性能测试范围

2.3.2 并发用户数评估

2.3.2.1 公式

2.3.2.2 例子

2.3.3 根据TPS估计

2.3.3.1 公式

2.3.3.2 例子

2.3.4 响应时间评估

2.3.4.1 用户感知正常响应时间的标准

2.3.4.2 用户感知特殊响应时间的标准

2.3.5 事务成功率

2.3.6 系统资源使用率

2.3.6.1 CPU使用率

2.3.6.2 内存利用率

2.3.6.3 磁盘I/O

2.3.6.4 网络带宽

三、性能测试通过标准（参考）

3.1 通用互联网服务端性能

3.2 用户感知正常响应时间的标准

3.3 用户感知特殊响应时间的标准

3.4 中间件的一些标准

四、测试工具介绍

4.1 商业版本

4.1.1 kylinTOP测试与监控平台

4.1.1.1 介绍

4.1.1.2 特性

4.1.1.2.1 自动化测试领域

4.1.1.2.2 性能测试领域

4.1.1.2.3 功能

4.1.1.2.4 架构

4.1.1.2.5 官网

4.1.2 kylinPET

4.1.2.1 介绍

4.1.2.2 官网

4.1.3 LoadRunner

4.1.3.1 介绍

4.2 开源版本

4.2.1 Apache JMeter

4.2.1.1 介绍

4.2.1.2 官网

4.2.2 OpenSTA

4.2.2.1 介绍

4.2.2.2 官网

4.2.3 Load impact

4.2.3.1 介绍

4.2.3.2 官网

4.2.4 locust

4.2.4.1 介绍

4.2.4.2 官网

一、性能指标介绍

1.1 并发用户数

指同一时间点对系统进行操作的用户数。准确说为"同时向服务器发送服务请求,给服务器产生压力的用户数量"

并发用户数和注册用户数、在线用户数的概念不同：

注册用户数一般指的是数据库中存在的用户数，在线用户数只是 ”挂” 在系统上，不一定对服务器不产生压力，而并发用户数一定会对服务器产生压力的。

1.2 TPS(每秒事务数)

TPS(Transactions Per Second)：每秒事务事，单位时间内处理的事务数量，它表示系统的处理能力，这个值越大，说明处理能力越强。

事务是一个或者多个操作的集合，可以一个接口、多个接口、一个业务、多个业务等等。

1.3 QPS（每秒查询率）

QPS(Queries Per Second):每秒查询率，是一台服务器每秒能够响应的查询次数(数据库中的每秒执行查询sql的次数)

1.4 TPS与QPS的区别与关系

1.4.1 区别

TPS：Transactions Per Second，意思是每秒事务数，一个事务可以包含一个操作，也可以包含多个操作。具体事务的定义，可以一个接口、多个接口、一个业务或者多个业务(业务流程)等等。
QPS：Queries Per Second，意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。

1.4.2 关系

如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps
如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tps
建议： QPS是Query Per Second，是数据库中的概念，每秒执行条数（查询），被引申到压测中来了，但是不包括插入、更新、删除操作，所以不建议用qps来描述系统整体的性能；

1.5 响应时间（RT）

指客户端发起服务请求到服务器处理完服务请求并返回结果给客户端的时间。

另：吞吐量（Throughput）含义

指的是单位时间内处理的客户端请求数量。

从业务角度来看，吞吐量指每秒事务数。单位：“Requests/Second” 从网络角度来看，吞吐量指每秒字节数，用来衡量网络的流量。单位：“Bytes/Second”

二、指标评估

2.1 背景

做性能测试之前，最好先定义清楚性能指标。这样我们才能评估测试结果是否满足预期。最理想的情况是，开发、产品、项目经理已经提前定义好性能指标。但是理想和现实的差距非常大。

2.2 获取性能指标

如果用户有明确的性能指标，直接使用即可；如果没有，首先要进行需求分析，以获取满足要求的性能指标，如通过业务调研、日志信息等获取系统最大在线用户数、业务分布、业务高峰时间段、业务高峰期业务量等。

2.3 性能指标计算/统计方式

2.3.1 性能测试范围

通过业务分布来确定性能测试的范围

2.3.2 并发用户数评估

2.3.2.1 公式

平均并发用户数的计算：`C=n*L/T`

并发用户数峰值计算：`C^=C+3*根号C`

n：平均每天访问用户数 L：用户平均每天的访问时长 T：被考察的时间长度，可以理解为一天内有多长时间有用户访问系统

2.3.2.2 例子

假设系统A，该系统有5000个用户，平均每天大概600个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为0.2小时，而在一天之内，用户只有在8小时之内会使用该系统。

计算：

平均并发用户数为：C = 600*0.2/8 = 15

并发用户数峰值为：C^ = 15 + 3根号15 = 27

通用公式对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。

比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，

根据二八法则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为：`50000*80%/（3*60*60）=3.7`

约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！

根据系统在线用户数计算：并发用户数 = 实际系统最大在线用户数的8%到12%

在进行并发用户数评估的时候，不仅要满足当前的性能需求，还要满足未来2~3年不断增长的业务量和用户量的需求。所以评估时候要考虑未来几年的业务增长率。

2.3.3 根据TPS估计

2.3.3.1 公式

公式为 C = TPS*( RT+Think time)

TPS(每秒事务数)：通过某时间段业务量的峰值来确定TPS(峰值才能真实反映服务器的最大处理能力)，

TPS=脚本运行期间总的事务数/脚本运行时长

如果使用集合点策略，在脚本执行前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不一致，比理想中的小。

中间可能会用到二八法则：指80%的业务量在20%的时间里完成。

TPS预估方法：进行业务调研，统计出业务分布(业务占比)、每个业务的高峰期以及每个业务在高峰期的业务量。也可以统计出总的业务量，然后根据业务分布及占比得出每种业务的业务量。

注意：业务量评估要考虑未来2 ~ 3年的业务增长，以满足未来的性能要求。之所以2~3年是因为我们不会几个月做一次性能测试，也不会做完性能测试之后就再也不做性能测试。

TPS计算，使用二八法则更准确。

2.3.3.2 例子

以目前生产核心系统交易量峰值680万笔/天为基数，每年20%的业务增长，柜面业务占比25%，上收业务占比柜面业务的40%。

计算前端系统三年后业务量为 `680万*（1+20%）（1+20%）（1+20%）*25%*40%=117.5万笔/天。`

以系统未来预期日交易量117.5万笔/天为测试目标，用常规性能测试TPS估算方法计算，峰值交易TPS为80%的交易量在20%的时间内产生，以系统交易时间12小时计算，测试目标TPS为：`(117.5万*0.8)/(120.2*3600秒) =109笔/秒`。

结论：限制TPS的原因：服务器本身性能、代码结构、客户端施加的压力以及网卡等。

利用并发用户数、期望响应时间，可以计算出TPS的期望值。TPS = 并发用户数/(RT+Think Time)，实际TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。虽然在宏观上是反比的关系，但是两者之间没有直接关系。

系统TPS会受到并发用户数的影响，刚开始会随着并发用户数的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。利用TPS与并发用户数图，可以分析性能瓶颈。

举例说明：当并发数增加到10的时候，响应时间始终都是1，TPS还在继续增加，说明并发不够，需要增加并发数以达到TPS的峰值。

如果继续增加并发用户数到20，而响应时间还是1，再增加并发用户数，响应时间小于1，说明TPS达到了峰值20。

继续增加并发用户数到100，则造成了线程等待，引起平均响应时间从1秒变成3秒，TPS也从20下降到9

2.3.4 响应时间评估

2.3.4.1 用户感知正常响应时间的标准

2-5-8原则：如果响应时间在2s内，用户会觉得系统很快；如果响应时间在25秒之间，用户会觉得系统的响应速度还可以；如果响应时间在28秒之间，用户会觉得系统的响应速度很慢，但还可以勉强接受；而当超过8秒后仍无法得到响应时，用户会觉得系统糟糕透了，或认为系统已经失去响应；

2.3.4.2 用户感知特殊响应时间的标准

普通业务操作响应时间：5秒内；

万级数据量查询响应时间：8秒内；

百万级数据量查询响应时间：10秒内；

千万级别数据量查询响应时间：20秒内；

2.3.5 事务成功率

单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般事务成功率要求100%或大于99%。

2.3.6 系统资源使用率

2.3.6.1 CPU使用率

指用户进程与系统进程消耗的CPU百分比，长时间情况下，一般不超过80%；

2.3.6.2 内存利用率

内存利用率=（1-空闲内存/总内存大小）*100%，内存使用率一般不超过80%；

2.3.6.3 磁盘I/O

磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用磁盘用于读写操作所占用的时间百分比度量磁盘读写性能；

如：Linux命令：iostat -d -x # -d 显示磁盘使用情况，-x 显示详细信息

%util：一秒中有百分之多少的时间用于 I/O，如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷

2.3.6.4 网络带宽

一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；

三、性能测试通过标准（参考）

性能测试通过标准包括服务端性能、前端性能和用户体验性能，常规通过标准如表所示：

3.1 通用互联网服务端性能

TPS(每秒事务数)大于期望值；

响应时间小于期望值；

错误率小于0.5%(事务成功率大于99.5%)；

CPU使用率小于75%；

JVM内存使用率小于80%；

3.2 用户感知正常响应时间的标准

2-5-8原则：

如果响应时间在2s内，用户会觉得系统很快；

如果响应时间在25秒之间，用户会觉得系统的响应速度还可以；

如果响应时间在58秒之间，用户会觉得系统的响应速度很慢，但还可以勉强接受；

而当超过8秒后仍无法得到响应时，用户会觉得系统糟糕透了，或认为系统已经失去响应；

3.3 用户感知特殊响应时间的标准

普通业务操作响应时间：5秒内；

万级数据量查询响应时间：8秒内；

百万级数据量查询响应时间：10秒内；

千万级别数据量查询响应时间：20秒内；

3.4 中间件的一些标准

当前正在运行的线程数不能超过设定的最大值；

当前运行的JDBC连接数不能超过设定的最大值；

GC频率不能频繁，特别是FULL GC更不能频繁，FullGC频率大于半小时每次。

四、测试工具介绍

4.1 商业版本

4.1.1 kylinTOP测试与监控平台

4.1.1.1 介绍

kylinTOP测试与监控平台是一款B/S架构的跨平台的集性能测试、自动化测试、业务监控于一体的测试平台，该工具开放10个免费虚拟用户可供学习和使用。在易用性上较好，录制脚本支持最新版本的浏览器，对谷歌和火狐都支持非常好。录制过程高效便捷这是其它性能工具无法比拟的。仿真能力上是目前业界做的最好的性能工具，可以做到完全仿真浏览器行为，也就是单用户的HTTP请求瀑布图可以和浏览器器完全一样。总之它是目前国内一款非常难得好用的性能测试工具，可以完全替代国外的同类产品。目前在军工领域、测评检测机构、国有企业、银行体系、大型企业有着广泛的应用。支持的协议较多，尤其在视频领域支持的协议非常多，具有独特的优势。

4.1.1.2 特性

4.1.1.2.1 自动化测试领域

首次引入AI概念，突破业界传统WEB UI、APP界面的自动化测试工具设计的思路，使用用例设计效率、运行稳定性、可维护性、易用性上有质的飞跃。该软件具有录制快速生成用例、元素智能定位、步骤智能等待、自愈技术(自动适应版本变化更新脚本变化元素)等一系列智能化特点，很好的适应了软件敏捷开发时代的需要。通过XRunner-kylinTOP使用者只要按正常的业务操作即可生成用例，后期即使定位元素变更也不会影响自动化测试的执行，提升测试效率、降低维护成本、提高测试稳定性，开启了软件自动化测试的智能化时代。
接口/协议自动化测试支持HTTP/HTTPS/HTTP2、Restful/REST/WebService、Dubbo、websocket、JDBC/SQL、Socket(TCP/UDP)、SIP、FTP、MQTT、自定义JAVA

4.1.1.2.2 性能测试领域

打破了国外企业垄断地位，首次使中国具有一款真正意义上的国产化软件性能测试工具。性能测试工具的仿真度、问题分析能力、资源消耗上要优于美国的LoadRunner。目前在军工领域、测评检测机构、国有企业、银行体系、大型企业有着广泛的应用。支持的协议较多，尤其在视频领域支持的协议非常多，具有独特的优势。
集成kylinPET性能测试能力，支持项目管理、多人多任务同时进行性能测试；支持WEB/WebService业务与Flex（HTTP/HTTPS/HTTP2）、MQTT物联网协议、XMPP、Socket业务、Dubbo(阿里分布式框架)、数据库、JMS、FTP/SFTP、WEB视频（包括FLV/MP4/HTTP Live Streaming/HTTP Smooth Streaming/HTTP Dynamic Streaming/RTMP）、WebSocket、JAVA、SMTP、POP3/IMAP；支持多种协议组合。

4.1.1.2.3 功能

4.1.1.2.4 架构

4.1.1.2.5 官网

国产性能测试工具-国产自动化测试工具-国产压力测试-UI自动化测试-性能测试工具-深圳市奇林软件有限公司 (70testing.com)

4.1.2 kylinPET

4.1.2.1 介绍

kylinPET在外观设计思路上有点类似LoadRunner,由脚本编辑器、分析器、并发控制器、执行器四部分组成，运行环境支持windows,linux,统信操作系统,麒麟操作系统。kylinPET工具在脚本录制上具有强悍的表现，脚本录制支持的浏览器包括：Chrome,Firefox,ie,UOS浏览器、龙芯浏览器等。优其对脚本的调试功能，有着不一般的表现：录制与回放对比、回放结果可视化展示、关联功能扫描等。

性能最主要的功能是脚本制作、场景配置、指标统计与监控。kylinPET在这三个方面都做到了极致。

4.1.2.2 官网

下载中心——kylinPET 铸造业界一流的性能测试工具

4.1.3 LoadRunner

4.1.3.1 介绍

LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具，能优化系统性能。它的测试对象是整个企业的系统，通过模拟实际用户的操作行为和实行实时性能监测，帮助用户能尽快查找和发现问题。

LoadRunner通过模拟一个多用户并行工作环境来对应用程序进行负载测试，当应用程序在负载下运行时，会准确地度量、监控并分析系统的性能和功能。

4.2 开源版本

4.2.1 Apache JMeter

4.2.1.1 介绍

JMeter是一款开源免费的压测产品，最初被设计用于Web应用功能测试使用，如今JMeter被国内企业用于性能测试。对于WEB服务器（支持浏览器访问），不建议使用Jmeter,因为jmeter的线程组都是线性执行的，与浏览器相差很大，测试结果不具有参考性。对于纯接口的部分场景（对接口调用顺序无严格要求）测试可以使用，但是要注意使用技巧，才能达到理想结果。Jmeter提供的脚本形态与kylinPET很相似，但执行行为相差很大。Jmeter在进行脚本调试时，关联参数都需要手工处理，需要消耗大量的时间。

4.2.1.2 官网

Apache JMeter - Apache JMeter™

4.2.2 OpenSTA

4.2.2.1 介绍

OpenSTA是一个免费的、开放源代码的web性能测试工具，能录制功能非常强大的脚本过程，执行性能测试。例如虚拟多个不同的用户同时登陆被测试网站。其还能对录制的测试脚本进行,按指定的语法进行编辑。在录制完测试脚本后，可以对测试脚本进行编辑，以便进行特定的性能指标分析。其较为丰富的图形化测试结果大大提高了测试报告的可阅读性。OpenSTA 基于CORBA 的结构体系，它通过虚拟一个proxy，使用其专用的脚本控制语言，记录通过proxy 的一切HTTP/S traffic。通过分析OpenSTA的性能指标收集器收集的各项性能指标，以及HTTP 数据，对系统的性能进行分析。

4.2.2.2 官网

OpenSTA Users Home Page - Free Web Load and Stress Testing Tool

4.2.3 Load impact

4.2.3.1 介绍

是一个在线可以免费测试网站负载能力，它就可以满足你的基本要求，当然成为他的付费用户测试的项目将会更多。

Load impact是一款服务于DevOps的性能测试工具，支持各种平台的网站、Web应用、移动应用和API测试。Loadimpact可以帮助用户了解应用的最高在线用户访问量，通过模拟测试不同在线人数下网站的响应时间，估算出服务器的最大负载。

4.2.3.2 官网

Load Impact is now k6

4.2.4 locust

4.2.4.1 介绍

Locust 完全基本 Python 编程语言，采用 Pure Python 描述测试脚本，并且 HTTP 请求完全基于 Requests 库。除了 HTTP/HTTPS 协议，Locust 也可以测试其它协议的系统，只需要采用Python调用对应的库进行请求描述即可。但是需要手工编写脚本，有一定的难度。