零、压测指标问题
压测指标,一定要需求方定 啊,谁提压测需求,谁来定压测指标。
如果需求方,对压测指标没有概念,研发和测试,可以把历史压测指标、生产数据导出来给需求方看,引导他们来定指标,千万别自己定啊。不然将来大锅要自己背的。
一、环境问题
1、保证本地环境(jmeter版本、jdk版本)与Linux负载机环境一致,不然可能会报错。
jmeter脚本,要禁用掉多余的插件(查看结果树、曲线图之类的)。
2、jmeter内存设置
要保证jmeter有足够的内存,不然启动或者写日志的时候,会内存不足的错误。
3、确认一下linux负载机,网络与被测系统的ulr是否时通的。可能会遇到ping不通的情况,可能是运维做了某些限制,及时与运维沟通
4、负载机与被测系统,要在同一个局域网内,为了避免网络带宽的限制,以至于负载机给不了足够的压力。
5、提前与开发/运维人员,确认被压测系统有没有过载保护之类的,比如有的有ip限制,同一个ip只能并发3个请求。
二、数据问题
2.1 系统体量
背景:为了测试在一定用户体量下的性能表现,需要提前向数据库中注入100万的用户数据。
1、向数据库注入数据之前,要确保造数据的脚本是正确的。需要先在其他备份数据库里尝试一下,不要造成脏数据
2、向数据库注入数据之前,要提前将现有数据备份一下,避免造数据,将现有数据弄乱。
2.2 压测使用的数据问题
1、要压测登录功能,需要提前准备十万条登录数据。将数据从数据库导出来后,要提前校验一下这十万条数据是否都可以用。
三、脚本问题
1、有的脚本,在低并发的时候不会报错,但是在高并发的时候会报错。
比如登录问题,当高并发的时候,会出现几个线程使用同一个账号进行登录,导致登录失败。
解决办法:
a、增大登录用户的数据量
b、使用循环控制器,依次读取数据
2、 缓存因素影响
查询类接口,是否有缓存,我们压测的策略也是不一样的。
在写压测脚本时,及时与开发沟通,哪些接口是否涉及到缓存影响。
或者我们直接使用参数化,这样即使有缓存,也会避免缓存的影响。(当然最好提前与开发确认一下哪些是否有缓存)
3、加密、验签等需要脚本处理
在压测接口的时候,有时候需要提前处理数据,加密啊、验签等。一定要使用java来处理这些,不要用js等这些歪门邪道的语言。
同样一个验签处理,用js处理,2分钟,打出了8000个样本请求。
用java处理,2分钟打出了300000个请求。 js脚本严重制约了性能。
四、流程问题
1、提前与运维、业务方、开发测试等项目相关人员确定是否对他们有影响
2、第三方依赖。有的系统需要依赖第三方,需要做挡板处理。
五、压测数据收集
记录压测开始与结束的时间很重要,方便开发查询定位问题。
使用命令:
jmeter -n -t /home/test.jmx -l /home/xx.jtl -e -o /home/xx_report/
生成的report index.html 会记录压测开始与结束时间。手动记录一下也可以。