jmeter性能测试总结

一、性能测试问题记录：

Ⅰ、秒杀的失败率了在96.45%，原因 Query对于 活动的秒杀采用的是0.5秒，刷新缓存的策略在活动中优惠券被秒杀一空

下架前，短暂的时间内仍能够查询到 这个活动架构中采用了CQRS模式只保证了最终结果一致性，并不能保证实时一致性。

Ⅱ、日志级别为Info，导致CPU很大一部分的是用来处理日志相关的功能，

Ⅲ、异步输出日志能比同步输出的方式下，提升了接近100%的吞吐量

Ⅳ、代码中存在大量数据库连接使用未关闭的情况，导致后续事务无法获取数据库连接

Ⅴ、logstach配置错误，导致redis数据无法及时导出，2G存储量很快被占满报错

Ⅵ、MQ队列使用错误，为每次事务单独建立了队列，且这些队列无法自动清除

Ⅶ、网关配置有误，导致限流发生；对接ERP方式代码有误；数据库配置错误，导致性能缓慢

Ⅷ、数据库出现死锁

Ⅸ、QPT(请求数)增加↑，TPS（吞吐量）没有上去，是因为当时服务器能处理就这么多

Ⅹ、服务器的配置确实偏弱，1核8G，需要同时跑网关、外卖等多服务，且此时并未分多节点部署

 

二、jmeter使用技巧点记录：

1、由于变量 无法在不同的线程组中共享和传递，这时候 Beanshell postprocess组件就排上用场了，它的作用将当前线程组中目标变量转换为全局变量

2、jmeter集合点：通过添加定时器来完成，只能作用于JVM中 

3、硬件服务器不足时，可采用Jmeter的分布式集群，远程启动测试

4、性能测试数据，除了.cvs、txt等一般模拟数据外，还可以使用 脱敏后的线上数据

 

三、性能测试经验小结：

1、性能测试一般都是需要进行多轮测试，因此，性能调优是一个循环过程

2、代码质量过关，性能测试就只是走个过场

3、性能测试可能找出开发编码不合理，同时也能 帮助运维找出更合适的系统应用部署方案

4、在性能测试过程中，系统架构图作用就很明显了，在日志报错信息不明确情况下，可以查看每部分的监控信息，

查出报错原因，如果没有架构图，则只能东一榔锤西一棒头，效率很低。

 5、log4j2的吞吐量相对于log4j1而言大幅提高了约40%，内存使用量也更少了。因此，推荐使用性能更佳的log4j2替换掉陈旧的log4j1。

四、性能需求指标项和指标值二八原则：

eg:，每日派件量1000W，按照2：8原则推算：

　　（1000W*80%）、（8*3600*20%）=1388.8，取整为1389笔/每秒

　　每年按照业务量增长50计算，一年后系统处理能力指标约等于：1389*(1+50%)=2083.3，取整为2084笔/每秒

　　按照稳定性交易量推导：取系统处理能力的80%计算：

　　80%*2084*8*3600=36011520≈3601W笔/天

 

 

五、性能工具引入：

1、Jmeter：用于进行负载和压力测试

2、jProfiler：用于进行性能测试分析

3、nmon：用于监控系统负载

4、zabbix：用于监控服务器硬件信息

5、pinpiont:分布式系统监控工具

6、Jmeter的PerfMon插件

7、当然也可以用云智慧的监控宝和透视宝协同工作，监控宝可以监控网站／网页性能／Ping/DNS/FTP/UDP/TCP/SMTP等IT基础设施的性能指标，透视宝可以发现主机资源、Web应用、浏览器、APP等应用的性能瓶颈，

监控宝监控页面：

六、性能实施流程：

1、性能测试流程分为五个阶段，分别是【需求调研阶段】→【测试准备阶段】→【测试执行阶段】→【测试报告阶段】→【测试总结阶段】。

2、性能需求提供者：一般为产品人员/业务方/研发人员

需求调研：需求调研工作由性能测试实施人员牵头负责，产品经理、开发工程师、运维工程师配合完成；

需求调研的主要内容为：系统线上环境的性能需求，例如性能需求、可靠性需求、可维护性需求等；

 

转载于:https://www.cnblogs.com/dayiran1222/p/8733404.html