性能测试

1，基础概念：HPS、TPS、QPS、RPS、RT、并发用户数概念？简要介绍？

HPS（Hits Per Second）：每秒点击次数，单位是次/秒。

TPS（Transaction per Second）：系统每秒处理事务数，简称TPS, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求

RPS 即每秒请求数（Request Per Second），通常用来描述施压引擎实际发出的压力大小。PS：并发数过低时可能达不到预期的 RPS，并发数过高时可能压力过大压垮服务器

并发用户数：简称VU ,指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。

响应时间：简称RT,指的是业务从客户端发起到客户端接受的时间。

2，压测工具？你主要看哪些指标？

答：jmeter：

Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值

#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100

Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

Median：中位数，也就是 50％ 用户的响应时间

90% Line：90％ 用户的响应时间

Note：关于 50％ 和 90％ 并发用户数的含义，请参考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小响应时间

Max：最大响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数

Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

3，性能测试中TPS上不去的几种原因浅析？

TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。

a、网络带宽 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

b、连接池

可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

c、垃圾回收机制

从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

d、数据库配置

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。

e、通信连接机制

串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。

f、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

g、压力机

比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

h、压测脚本

还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。

提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。

i、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

j、系统架构

比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

4，性能测试工具了解几个？压测结果区别？

A，ab，是apache自带的压力测试工具

B，Jmeter 基于Java的压力测试工具

c，Locust是一个Python编写的分布式的性能测试工具

5，性能测试策略？

做性能测试需要一套标准化流程及测试策略。在做负载测试的时候，传统方式一般都是按照梯度施压的方式去加用户数，避免在没有预估的情况下，一次加几万个用户，导致交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内；较为适合互联网分布式架构的方式，是用TPS模式（吞吐量模式）+设置起始和目标最大量级，然后根据系统表现灵活的手工实时调速，效率更高，服务端吞吐能力的衡量一步到位。

6，性能测试场景设置思路？

无论并发模式还是TPS模式，场景就是一个压测模型，压测模型中有串行的事务（如添加购物车+购物车下单+付款）也有并行的接口（在不同串联链路中的压测API），最终组成一个复杂或者简单的场景。然后根据新业务上线的目标、或者日常峰值的等比例目标、或者重大业务活动的预估支撑能力去设置每个API的目标能力（TPS是一步到位的按照吞吐能力设置的，推荐TPS模式，比如前面提到的添加购物车+购物车下单+付款这种流程就是一个漏斗模型，TPS设置为逐渐变小的模型即可），当然也可以在初期的测试中更谨慎一点，将目标量级设置得整体低一点，当最终能力达到之后建议可以调整原定目标量级到120%或者150%，验证限流准入/高可用基础设施的抗压能力。目标量级即当前压测场景中这个压测API的施压上限。而起步量级可以从5%或者10%开始，过程中视业务指标数据和被压测端的整体负载临时调整。

7，对服务器性能测试的看法？

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到串联链路（场景）中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。同样的，如果系统间的吞吐能力差别很大，那么同样的并发下TPS差距也会很大

8，系统的性能决定的要素？跟并发用户数的关系？

由TPS决定，跟并发用户数没有多大关系。

系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。

建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。

Sample:本次测试场景共运行多少线程；

 Average:平均响应时间； 

 Median:统计意义上的响应时间中值；

  90% line:所有线程中90%的线程响应时间都小于xx的值;

  Min:响应最小时间；

 Max:响应最大时间；

 Error:出错率；

Throughput - 吞吐量以“requests/second、requests /minute、 requests /hour”来衡量。 时间单位已经被选取为second，所以，显示速率至少是1.0，即每秒1个请求。 当吞吐量被保存到CVS文件时，采用的是requests/second，所以30.0 requests/second 在CVS中被保存为0.5

Kb/sec - 以Kilobytes/seond来衡量的吞吐量