浅谈性能测试问题定位

什么是系统的性能？

当一个系统被开发出来后，功能均被实现了，系统进入稳定的运行状态。但系统的运行得怎么样，还是有待验证。系统的运行得怎么样即可以简单理解为系统的性能。

什么是系统的性能测试？
在指定的软件、硬件、网络条件下，通过编制脚本运行模拟多种环境进行测试（如：正常环境、峰值环境、负载环境等）对系统各项性能指标进行测试，从而发现系统的性能瓶颈。
简单来说，就通过测试策略，测定工具，模拟真实的用户使用环境验证系统运行得怎么样。

性能测试目的：并发、负载（最多容纳多数人）、稳定性（高负载的情况下是否稳定）、极限（拐点、压崩：故障转移是要压崩溃的）

性能测试准备
1. 性能测试对象及目标
测试对象可以归结为“业务功能”。测试前，需要了解我们需要测试的业务功能（不深入细节）有哪些，比如“购买商品”、“寄送快递”。

有没有必要测？需求来源哪里？，有没有数据支撑测试这个需求的必要性？
通常，可以从以下几个方面考虑：
1）是否核心功能，是否要求严格的质量
2）是否常用、高频使用的功能
3）可能占用系统较多资源的功能
4）使用人数多还是少
5）在线人数多还是少

拆分对象
先从业务上来分，实现这个完整的功能包含哪些流程、环节
举例：购买商品
登录->搜索商品->提交订单->支付订单->退出

指标分析
分析性能需求指标（如“支持300人并发登录”）是否合理
有必要测试这个需求，考虑需求指标是否合理？有没有数据支撑？
1）采样时间段内系统使用人数
2）采样时间段内系统在线人数
3）采样时间段内系统(页面)访问量
4）采样时间段内请求数

常用分析思路：
2/8法则
2/8法则：80%的业务量在20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等

2. 服务器是什么系统
3. 服务器IP地址
4. 服务器和软件配置
5. 测试机配置（考虑是否需要分布式测试）

性能测试指标

1. 响应时间：
指的是从客户端发起请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。一般为258原则，或1357原则：1s优秀，3s良好，5s及格，7s不合格。

2.平均响应时间：
所有请求花费的平均时间

3.90%的响应时间
90% 的请求响应时间都处在这个值以下
如：如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms
平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms
在评估性能测试结果时，除了要考虑事务的平均响应时间，还要考虑90%的响应时间。

4. 吞吐量
吞吐量是我们常见的一个软件性能指标，对于软件系统来说，“吞”进去的是请求，“吐”出来的是结果，而吞吐量反映的就是软件系统的“饭量”，也就是系统的处理能力
简单来说，就是单位时间内处理请求的数量。
吞吐量越大，表示服务器的CPU处理请求的速度越快。

5. TPS
每秒钟系统能够处理事务或交易的数量，衡量系统处理能力的重要指标
TPS峰值是指在响应时间合理范围内TPS的最大值，一般取TPS峰值并发数的75%，持续1小时进行稳定测试

6.点击率
单位时间用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标：WEB应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。
点击率越大，对服务器的压力越大。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。

7 .思考时间
即请求间的停顿时间。实际中，用户在进行一个操作后往往会停顿然后再进行下一个操作，为了模拟这种用户行为而引入了该概念
而什么时候需要设置思考时间呢？
为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。
举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。
如果我们不设置考虑时间，对2路A的脚本，1路B的脚本进行性能测试
在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，A查看帖子由于响应时间短，因此跑的次数更多，最后的比例可能是4:1
上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。

8.资源利用率
指的是对不同系统资源的使用程度，例如服务器的CPU（s），内存，网络带宽等。资源利用率通常以占用最大值的百分比n%来衡量。

**性能结果分析

1.压测结果指标**
Samples:表示一共发出的请求数
Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好
聚合报告中的，吞吐量=完成的transaction数/完成这些transaction数所需要的时间；平均响应时间=所有响应时间的总和/完成的transaction数；失败率=失败的个数/transaction数总的来说，对于jmeter的结果分析，主要就是对jtl文件中原始数据的整理

2.压测结果分析
Error%:确认是否允许错误的发生或者错误率允许在多大的范围内；
Throughput：吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
压测结束，登陆相应的web服务器查看CPU等性能指标，进行数据的分析;
最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。
最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。
影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。

3.性能测试关注点
1.客户端响应时间是否满足要求
2.服务器资源使用情况是否合理
3.应用服务器和数据库资源使用是否合理
4.最大访问数，最大业务处理量是多少
5.系统可能存在的瓶颈在哪里
6.能否支持7*24小时的业务访问
7.架构和数据库设计是否合理
8.内存和现成资源是否可以被正常回收
9.如果系统出现不稳定情况，其可恢复性如何

1.CPU、TPS存在明显波动则存在瓶颈
2.并发时服务日志级别需调整为error级别
3.通常请求由一个线程负责执行，占用一个逻辑CPU
4.若并发量增加而CPU使用率未增加则存在瓶颈
5.CPU负荷集中在应用服务器和数据库服务器上
6.内存负荷集中在应用服务器和数据库服务器上
7.磁盘负荷集中在数据库/文件服务器上
8.对外网络流量集中在负荷均衡器（nginx、LVS）上