一、90%响应时间（参考虫师博客）

90%Line 

一组数由小到大进行排列，找到他的第90%个数（假如是12），那么这个数组中有90%的数将小于等于12 。

用在性能测试的响应时间，也就是90%请求响应时间不会超过12 秒。

例如：

某一次测试结果，每个sample的响应时间分别是：1、3、4、9、2、8、5、7、6、10，将其按由小到大将其排列为：

1、2、3、4、5、6、7、8、9、10    

那么它的第90%百分位，也就是第9个数刚好是9 ，那么他的90%Line 就是9 。即90%响应时间是9ms，理解为：90%的用户请求时间不冲9ms。

另一测试结果，20个sample，响应时间分别为：

2、2.1、2.5、3、3.4、3.4、4、4、4、4、5、5、5、5.9、5.91、6.8、8、12、24、24.1   按由小到大将其排列。

求它的第90%百分位，第18个数是12 么，他的90%Line 就是12。 

二、事务

1、事务的组织

计算机术语中，事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

在性能测试脚本设计中，事务的设置至少应该遵守原子性，即不可分割性。

如购物事务一般包括登录、查找商品、查看商品详情、加入购物车、结算几个步骤，每个步骤都缺一不可；

又比如转账业务（A账户向B账户转出50元），包括A账户-50元、B账户+50元两个步骤，每个步骤缺一不可。

再比如百度搜索，包括两步：打开百度首页，输入关键字搜索，两个步骤组成一个搜索事务。

常用的场景

1、事务=单个请求

2、事务=思考时间+单个请求

3、事务=多个相关联的请求

如果事务中增加思考时间，运行结果统计的事务响应时间是包括思考时间的，所有场景的设计，脚本的设置，对测试结果是有影响的，具体需要根据需求进行设计。

2、项目举例

项目一

需求：测试一个系统的TPS

分析：该系统包含多个功能点，选择主要的功能点进行压测

设计：每个功能点设计为一个事务，每个事务包含N个请求，通过脚本描述。

项目二

需求：有一个接口，用于跟踪用户行为，一旦用户登录就上传用户的登录时间。要求：测试一下性能看能撑多少用户同时在线。

分析：单个接口（请求）无需事务概念

项目三

需求：测试一下某个电商系统能同时支持多少用户下单并购买成功

分析：业务是下单并购买，包含多个请求，需要组织成事务

三、TPS

1、TPS、TPM、QPS、PV

pv 是指页面被浏览的次数，比如你打开一网页，那么这个网站的pv就算加了一次；
tps是每秒内的事务数，比如执行了dml操作，那么相应的tps会增加；

tpm是每分钟的事务数。
qps是指每秒内查询次数，比如执行了select操作，相应的qps会增加。

不同的应用系统tps,qps是没有可对比性的。
例如：
应用A，每个select查询需要1ms, 一个connection的话，一直不停的执行，1S内 可执行1000次，也就是1000qps
应用B，每个select查询需要100ms, 一个connection的话，一直不停的执行，1S内 可执行10次，也就是10qps

上面不同系统的两个qps是无法对比的，不能说哪个好哪个坏。

2、TPS的作用

例一
某单个接口，tps=10，希望这个接口每天能处理100万个请求，问能否满足？
1）每分钟处理60*10=600个请求
2）每小时处理600*60=36000个请求
3）每天处理24*36000=864000个请求
不能满足需求
 
例二
希望某个接口每天能处理200万个请求，问TPS至少应该达到多少？
200*0000/24*3600=28
 
例三
钉钉打开系统，9:00上班，8:30-9:00期间打开，一般集中在30分钟。
公司500人，平均每个员工打卡1.6次（有人怕没打上会再打），算一下TPS多少能支撑目前的应用不挂？
tps=500*1.6/30*60=0.44
如果是10分钟以内打完卡
tps=500*1.6/10*60=1.3
如果是集中在最后一分钟
tps=500*1.6/1*60=13
 
假设现在一台服务器的tps是7，那么至少需要2台服务器
这两台服务器平时都很闲，只有上下班时才忙，该如何设计？（类似的还有新浪微博，流量激增时可能需要1000台，平时500台即可）
使用动态扩容，热点警告
 

3、常用的应用场景

tps常常是有限制的，如cpu<80%,内存<60%时的tps

cpu使用率和内存占用率往往是默认的或取经验值

CPU	内存	用户数	tps	策略
已知	已知	已知	？	按指定用户数，设置释放策略，持续较长时间（30分钟），监控CPU、内存，取平均tps
默认	默认	？	已知	持续加压（增加用户数）看何时能达到目标tps，同时监控系统资源
经验值	经验值	？	？	什么都不知道的情况下，cpu、内存取经验值，持续加压，看系统的最大tps
？	？	不用太多	？	稳定性测试，用户不用太大，长时间运行（永远），监控cpu、内存、tps

 

 

 

容量测试：一般可设置运行1小时

压力测试：一般可设置10分钟

稳定测试：7*24小时、5*24小时

很不明确的需求：一般测试最大TPS

4、常见问题

如果某一次测出的TPS非常小，怎么办？

可能的原因

1）服务器处理能力本如此

2）负载机的用户数没发出去，如给10个用户，只发了3个用户。如果是这种情况，可以用siege试一下

3）如果这时的CPU和内存占用也很小，可能是网卡满了

5、性能调优的本质

拿时间换空间
拿空间换时间

时间：响应时间

空间：缓存

三、并发

1、并发量怎么理解

测试计划包三个线程组，分别如下：

线程组1：线程数200，Ramp-Up Perios200秒——每秒并发1

线程组2：线程数200，Ramp-Up Perios100秒——每秒并发2

线程组3：线程数200，Ramp-Up Perios10秒——每秒并发200

测试计划运行时是同时运行的，无delay。

并发分析

前10秒：200+1+2=203

10秒到100秒：1+2=3

最后100秒：1

第0秒：user1被创建，执行所有的samples用了10s,并发1

第1秒：user2被创建，执行所有的samples用了10s,并发2（user1+user2）

…

0秒——10秒，并发量递增1.2.3….10

第10秒：user1执行完退出，user11被创建，并发量10

第11秒：user2执行完退出，user12被创建，并发量10

…

10秒——200秒，并发量稳定保持在10

所以，一个用户的存活时间可以影响并发。jmeter报告中一般会有一个平均并发数

2、实际案例

某场景要求：100个用户，希望每秒并发数是100。该怎么做？

（1）100用户，20s释放，逐渐加压

（2）用户创建后不让其退出，循环次数设置为永远

（3）这样第20秒时，肯定能达到100并发，更加精确。

所以如果要精确控制并发量的话，建议thread不退出（永远循环），通过调度器设置运行时间。