jmeter性能测试总结

1、性能测试问题记录：

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

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

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

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

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

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

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

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

Ⅷ、数据库出现死锁

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

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

 

2、jmeter使用技巧点记录：

一、因为变量 没法在不一样的线程组中共享和传递，这时候 Beanshell postprocess组件就排上用场了，它的做用将当前线程组中目标变量转换为全局变量

二、jmeter集合点：经过添加定时器来完成，只能做用于JVM中 

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

四、性能测试数据，除了.cvs、txt等通常模拟数据外，还可使用 脱敏后的线上数据

 

3、性能测试经验小结：

一、性能测试通常都是须要进行多轮测试，所以，性能调优是一个循环过程

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

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

四、在性能测试过程当中，系统架构图做用就很明显了，在日志报错信息不明确状况下，能够查看每部分的监控信息，

查出报错缘由，若是没有架构图，则只能东一榔锤西一棒头，效率很低。

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

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

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笔/天

 

 

5、性能工具引入：

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

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

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

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

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

六、Jmeter的PerfMon插件

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

监控宝监控页面：

6、性能实施流程：

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

二、性能需求提供者：通常为产品人员/业务方/研发人员

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

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