【性能测试】性能需求挖掘、性能方案制定及压测场景设计之疑惑与思考（一）

压力测试

模拟用户在同一时间对服务器发送大量请求，以此查看服务器性能指标，尤其关注大业务量情况下运行系统性能的变化（反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复），测试系统的限制和故障恢复能力，找系统瓶颈

1、需加集合点，模拟用户瞬间并发，对服务器冲击力大

2、只执行一次，不需设置持续运行时间

3、每3秒进5个人，用户达到30 50 80集合后分别压测，然后利用二分法不断取中间值，找出最大吞吐量

并发用户数

实际就是在线用户数,相对并发用户数,在一个时间段内，与服务器进行了交互、对服务器产生了压力的用户的数量。这个时间段，可以是一天，也可以是一个小时

1、并发用户数标准不能以注册用户数为标准，应以在线用户数为标准或同时发请求用户更准，或注册用户数20%

2、并发用户数= 系统总用户数20%—30%

3、并发越大，响应时间越长，也跟吞吐量和服务器处理能力有关

4、每隔5分钟增加一定的并发数，直到达到瓶颈数，即线程数增加了以后tps处理量不在增加了，这个线程数可以算成合理的并发数。

负载测试

测试在一定负载情况下系统性能，逐步增加用户数量或用户请求来对系统进行加压，直到系统响应超时或关键资源耗尽，得到不同负载下系统性能指标，不关注稳定性。（关注最大安全临界负载量、吞吐量）

1、不加集合点，逐渐增加用户到系统瓶颈。对服务器冲击力小

2、需设置持续运行时间

3、逐渐增加用户，持续运行，直至达到系统瓶颈

稳定性测试

网站承受的最大负载值下，持续长时间运行，以此查看服务器的稳定性

1、不加集合点，逐渐增加用户到最大负载量（负载测试最大点）

2、达到最大负载需设置持续运行时间

3、逐渐增加用户到最大负载量，然后再持续运行一段时间（稳定性测试时长），然后逐渐退出

故障转移测试

恢复测试，是要把服务器压崩溃，测试另一台服务器是否可正常顶上

系统用户数（注册用户数）

在线用户数（相对并发用户数）

绝对并发用户

主要是针对某一个操作进行测试，即多个用户同一时刻发起相同请求,验证是否存在并发逻辑上的处理问题，如线程不安全、 死锁等问题；也可提供一些性能上的参考

日常压力(日常数据分析)

测试场景，就是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量。

高峰期压力(日常数据分析)

是指系统正常的、预期内压力的一个高峰

峰值压力，不在正常预期内的压力

性能指标:

1、吞吐量

服务端返给客户端的数据量，是指对网络单位时间内成功地传送数据的数量，是单位时间服务器处理事务的总数

Tps 是服务器每秒处理的事务字节数

随用户数逐渐增多，吞吐量应该是递增，如果吞吐量下降，服务器处理事务能力下降，响应时间变长，达到系统瓶颈

2、请求响应时间

从客户端发起的一个请求开始到客户端接收到服务器返回结束所耗费的时间=网络响应时间+应用层响应时间

3、事务响应时间

用户的一个操作的响应时间，是由一系列请求的响应时间组成

4、CPU

中心处理单元，由控制单元和运算单元组成，对数据进行处理，并发出控制命令，协调周边设备运行，对数据判断极逻辑处理，不能存储数据，从内存中读取数据进行逻辑计算，如果内存中没数据，才会从硬盘中读数据到内存，再进行逻辑计算，不能高于75%

5、错误率

6、内存

liunx内存工作原理，内存8g 优先分出7g 一部分分给应用，一部分分给缓存内存，放应用内存不足时，会把缓存内存优先分给应用

性能问题及其BUG

1、大数据量下，产生的性能问题

2、大访问用户量下，产生的性能问题

3、预估未来数据量，产生的性能问题

4、大结果集下，产生的性能问题

5、大复杂逻辑下，产生的性能问题

6、数据库产生的性能问题（未分库、未分表、未主从分离、数据库结构、SQL慢查询、实时查询、索引优化(建立主键或唯一索引、未使用联合索引)

7、性能缺陷：（并发错误、死锁、内存泄露）

8、cpu处于70%-100%之间波动

需求产生

分析用户是如何使用系统，用户对哪些业务性能比较敏感，系统的一些关键业务实现逻辑，从设计实现的角度来看哪些业务的性能可能存在隐患

通过友盟、阿里云、埋点、数据库、产品、运维等收集信息，分析系统、分析业务、分析用户行为等

注册用户数、在线用户数、日常压力、峰值压力、高峰期压力

1、产品、研发有明确需求

2、无明确需求，初次上线系统，需用同行系统数据，进行用户行为分析和商业数据结构的估算，利用性能估算推算，帮助决策，形成性能需求

3、无明确需求，已上线系统，通过运维获取tps和时间比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据，得出性能需求

4、无明确需求，系统关键模块、性能隐患模块、用户敏感性能模块，确定性能需求

5、无明确需求，根据用户的使用行为，使用习惯，确定性能需求

6、无明确需求，参考系统历史3个月/6个月/1年数据、用户历史行为，预测未来数据，确定性能需求

7、无明确需求，进行峰值测试或稳定性测试，测出系统的性能瓶颈，评估是否达到预期。

需求分析

1、系统类型、特点、架构和设计

2、深入理解被测系统，确定系统的关键业务模块，从设计实现逻辑确认性能隐患的模块、用户敏感的性能模块、用户使用行为，整理测试思路、制定测试方案、产生测试场景

3、 如果没有明确的性能需求，则根据历史数据或类似系统，由项目组评估出性能指标；

4、进行峰值测试或稳定性测试，测出系统的性能瓶颈，评估是否达到预期。

测试准备

1、控制机、压测机、压测环境

2、测试数据、业务数据 、测试性能模拟的压力数据、

3、数据来自生产环境、最大可能模拟生产数据

4、根据经验预估的数据、根据历史数据预估的未来数据

环境准备

1、操作系统、服务器配置分析，需了解系统的架构和设计

2、了解cpu信息

3、用户量（PV、PU、业务量）

4、服务器重启重置环境，干净的系统环境，无运行程序和脚本

5、负载机环境

6、测试环境要尽量的模拟生产环境

压测场景模拟（模拟所有可能发生的极端的访问情况）

基准测试、日常压力测试、峰值压力测试、绝对并发测试、稳定性测试

压测策略

1、基准测试，一个用户循环压5分钟 获取系统在没有压力的情况下响应时间，为下一步测试性能拐点做比对

2、负载测试，单个交易多个用户并发10，测试验证系统并发情况下是否有并发性的错误 应用锁 数据库锁

3、容量测试，多个交易按一定比例去配比 再按一定的体度 一定的梯度10 20 30逐步去施压，到获得这个系统的性能拐点，资源站用达到很高

4、稳定性测试 一定压力下长时间运行稳定的能力，是不是存在内存泄露、数据库查询慢

1、疲劳压测（稳定性压测），持续压测5小时，测试性能指标

2、并发压测，单接口瞬间启动100线程并发，测试性能指标

3、日常压测，根据每日数据分析，如：500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量，测试性能指标

4、业务压测，多接口业务流程压测，测试性能指标

5、峰值压测（极限压测），测试最大并发量，测试性能指标

6、阶梯压测,逐渐改变线程数进行压测，性能指标

7、大数据压测，数据量过大进行压测，性能指标

8、负载测试，分别压测50、100、150时，性能指标

9、数据库读写压测

案例：

1、比如购物：30个用户模拟登陆，10个用户浏览商品，30用户商品下单，20个查订单，10个做退出登录

2、25线程，5s后启动5个线程，再每隔5s启动5个线程运行10s，达到10线程运行20s，每隔3s停5个线程

3、2000用户在线登录状态，这2000用户中要达到100用户并发去访问首页，总的线程设置2000并发，其中95%的用户是登录状态，5%用户访问首页状态，采用固定定时器和吞吐量控制器

4、1w用户在线，模拟1w用户登录后操作一些系统中各个页面

5、【日常压力】活跃用户500人，每人每天发1帖子、浏览10帖子，平均每天产生500新帖子、浏览帖子5000次。用户使用论坛时间段集中在中午11点到1点和晚上18点到20点。每天的这些业务，实际分布在4个小时中完成的。那我们测试场景，就是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量，注意“平均每天……”、“分布在4个小时……”。这个场景测的是平均压力，也就是一个系统最平常一天的使用压力

6、【高峰期压力】比如“平均每天总的发帖量……”，那么就要查过去最高一 日的业务量。“分布在4个小时”也需要进行相应的修改，或查下历史分布图是否有更集中的分布，或用更简单通用80-20原则，80%工作在 20%时间内完成。根据这些数据可以再做适当的调整。

7、按照时间，使用递增的线程并发数来测试，比如每5分钟加5或10个线程，一直测试1小时，查看系统性能是如何波动的，这样就能基本找到产品的最大极限值即峰值、性能拐点

8、比如：一个系统日均1万人访问，一天平均3次/人，一般集中在每天晚上8点-10点，则我们可以算出每天1万人*3次/人=3万次请求，1天3万次请求集中在8点到10点3个小时之内，3万次请求集中在3小时之内，则平均每小时访问1万次请求，则每秒就是10000次/3600s大约为3次/s，即根据以往运营日志得出每秒钟3次请求，按照我们的并发峰值4倍的策略，则我们的性能指标可以定在4*3=12次/s，即我们的每秒处理事务数可以按照12次/s的基础来参考。

结果分析（硬件配置-操作系统-数据库-中间件-后端应用-前端应用）

1、服务器性能（哪些资源cpu占用过大、内存占用、硬盘占用、I/O读写）

2、Tps每秒处理事务个数 每个事务处理的平均时长

3、TPS（每秒处理请求数）、响应时间（服务器响应时间+网络时间）、错误率、QPS（每秒从服务器接收的数据量）

4、数据库（或中间件）非常慢了

5、中间件无响应

JVM堆内存用满，不停的进行GC，导致响应超慢（但是还没有OOM，否则就报错了）处理HTTP请求的线程，都被占用或者锁住

6、系统响应慢、超时、失败

7、服务器挂掉

8、网络（防火墙是否开启、端口的访问、宽带是否有被限制、路由寻址、网络的时延）

9、代码性能

10、定位分析问题：

10-1、网络忙不忙 网络延迟大不大 网卡流量 是不是达到网卡瓶颈

10-2、操作系统 应用服务器和数据库服务器资源cpu、内存占用、io读写

10-3、数据库锁 运行等待等

10-4、应用系统日志死锁 wait

10-5、前端连接数是否正常

10-6、与运维确认是否开了流量控制

10-7、再尝试重启应用服务器和数据库服务器

性能调优

1、扩充服务器（网路、cpu、内存、硬盘、显卡、I/o）

2、代码调优

3、中间件

4、分库、分表、主从分离、数据库结构优化、SQL优化、索引优化(建立主键或唯一索引、使用联合索引)

4.1、SQL优化

大表 左关联 小表，很慢；小表 左关联 大表，很快

嵌套的子查询是很慢

5、多个服务器负载均衡、使用缓存服务器

6、设置虚拟内存

7、运维设置限流

8、添加缓存、图片资源压缩

测试报告

性能测试比对 1 每次版本性能测试比对 2 机器横向增加 ，增加前后性能测试的比对 3 性能优化 优化前后的性能测试比对

如何确定系统性能测试tps需求标准？

已上线项目

查看过去1周（或1月）内，接口调用量最高的1天，然后再找当天接口调用量最高的时间点（分钟级别），比如在12:10调用量为10000，换算为每秒调用量10000/60=166，因此可以确定这个接口tps只要达到166即可满足。

未上线项目

二八定律（无历史数据参考） （日活用户*总请求数*80%）/（24h-（0-6h）*3600秒*20%）*系数（2-5之间）=tps

1、先预估系统每日总请求数，如果没有历史数据参考，一般是通过用户量或者其他关联系统来评估。

比如某网站新增每日签到送积分功能，网站注册用户1000w，日活跃用户100w左右，最极端情况下，这100w人都会来签到（实际不会这么多人来签到，评估指标要尽量往高评，以免出现极端情况），那么每天大概有100w次签到请求，80%的请求数就是100w*0.8=80w。

2、再确定系统20%时间，大多数系统是24小时对外提供服务的（比如政府类项目，在一天某个时间段提供服务）。

一般系统0点-6点之间访问量很少，从一天总访问量来看，可忽略不计。那20%的时间=（24-6h）*3600s*20%=12960秒。

3、最终计算出来的结果为80w请求/12960秒=61左右。也就是说接口TPS满足61即可。

4、最后再乘以一个冗余系数2-5之间，提高预期指标，防止人为评估造成预期指标偏低情况。

可以通过对项目接口的峰值监控，来对比之前评估的算法结果，调整冗余系数，最终随着不断的数据积累，将会形成一套本项目的性能模型。