压测噩梦后的小感想

近几天有幸接到并完成人生中的第一个压力测试,2.5天的时间,从0到现在,感触颇为复杂,特意记录一下,捋一捋这几天的收获。我想分以下几点展开本文:

  • 接受压力测试任务时的状态
  • 执行压力测试的过程
  • 最后对于这次经历的一个小总结
  • 下一个阶段想做的一点事情

刚接到任务时的凌乱

上周四下午,项目组让复测一个功能,跟领导说了这事儿,本以为手动测测一下功能的瓶颈就够了,结果快下班的时候,领导说让写一个脚本来压一压这个功能。其实,从一开始踏进测试大门,我就坚定要学做压力测试,并且还在写绩效合同时跟领导表达了我这一意向。可如今,突然接到领导这样的指示,就两个字——凌乱。

一直只知道loadrunner是做性能测试,但是目前还不知道怎么做,而且,似乎还有点复杂,什么场景设计,一看就懵。后来,同学推荐说可以用jmeter,说很好学用起来easy,我就下了个jmeter,装了后,看看发现也是先录制脚本,可以下载个badboy来录制脚本,跟jmeter关联可以导出脚本到jmeter,也可以直接用jmeter来录制。于是down下来jmeter,根据网络上的教程装了一下,研究了一下该怎么设置,怎么使用,自己也试着录制,但是还是不是很明朗。后来同事说公司都统一使用LoadRunner,我就立马再装LR了,还好,装成功了,在我本机。于是LR第一站便开始了。

执行压力测试的过程

自己从书上、网上学习LR的脚本录制/脚本重放/controllor的使用/怎样设计场景,以及对于我现在要做的这个压力测试,要如何设计场景才比较合适。

首先看到网上以及书上的负载处理的案例,我意识到,领导说的模拟连续向系统导入数据,其实更好的或者说更正确的描述应该还是多用户并发向系统执行极限数据量导入操作。于是,跟开发的同事确认了,目前除了限制5个用户,其余响应时间等参数,用户都未提出需求,而只是我们给用户做了一些限制。明确了负载的目的:5个用户并发分别向系统导入15*100*6*400的这种数据,看程序运行是否稳定/服务器运行是否稳定(资源占用情况)。

1、脚本录制

在录制过程中,又意识到每个用户登录时需要输入验证码,但是验证码每次都是变化的,于是借鉴之前自动化测试,也让该项目组同事将验证码屏蔽或者改为万能验证码了。自己就开始录制脚本,创建事务,插入集合点、检查点。第一遍都会比较生疏不确定,但大胆操作两边就更有底气了。

2、参数化

书上一直有提到的参数自动化,这一步还是挺模糊,初次接触压测,还以为参数化是要定义参数并赋值这样的。后来书上内容太多,于是请教了同事,将参数化弄明白并完成了参数化。

3、脚本重放

完成参数化,便replay一遍,结果是NO ERROR DETECT. 欣喜地进行下一步,也是最最混沌的——场景设计。

4、场景设计

设计几个用户、如何初始化用户(如几秒钟初始化一个)、何时作为集合点最好、是让其循环跑一段时间还是循环跑完任务就结束。其实,确定了这些,场景设计也差不多了。

5、使用controllor执行脚本

在这个过程中,时常会出现一些问题,比如找不到文件、或者文件是个空文件、或者timeout。

对于找不到文件的问题,百度后发现是录制时文件在哪里不重要,重要的是在重放脚本、controllor中跑脚本时,文件必须要在脚本的目录下。

对于文件是个空文件的问题,经常是因为录制的问题,必须保证录制时文件的导入执行是正常的,对于功能上的正常报错,在脚本录制过程中若出现便会带来问题。只能重录了。

而对于timeout的问题,就是http请求/响应的timeout、还有一个server 响应时间的设大一点。第一次改为1000时,发现还可以,后来改为1500都还是不行,不得不改为了10000??。总算是可以了。

6、Analyse

这一块儿,应该是性能测试最难的部分,如何评估、优化系统性能——我只能说我还只是个菜鸟????。只能请假一些有经验的公司同事一致认同的性能测试大神来帮助我了。对于其中有不合理的图表情况,我就重新造数据再跑了一遍脚本,终究与其余场景结果达成了一致。

终于能出报告了,却发现,忘了监控服务器资源使用情况。。悲了个大剧!!!于是,在网上查怎么使用LR监控远程服务器。发现有一步net user这个指令,成功地提示我53系统错误,按照网上查的方法找到服务器的lanmanserver开启,????,打开服务器的管理服务里,根本找不到这个玩意儿,好吧,为了快点出报告,我就先肉眼观察cou使用情况了。。大神告诉我,我现在最适合肉眼观察,使用LR远程监控对于菜鸟来说还是要求有点高。当然,这也将成为了我下一步必须克服的一个困难。

小总结

对于本次经历,我有两点想说:

  第一,遇到一个新的任务或者问题,有压力,也正是成长的时候,常在舒适区,很 难进步;

  第二,做事情最好要有条理,列好清单、流程,还得细心。比如测试过程中,我就是一不小心把文件名写错一个数字。

下一阶段想做的事

  a、能使用LR执行远程监控服务器,

  b、熟练使用LR的analyse功能,为项目带来性能上的优化

时间: 2024-10-18 06:53:43

压测噩梦后的小感想的相关文章

京东全链路压测军演系统(ForceBot)架构解密

摘要:全链路压测是应对电商大促容量规划最有效的手段,如何有效进行容量规划是其中的架构关键问题.京东在全链路压测方面做过多年尝试,本文转载京东商城基础平台技术专家文章,介绍其最新的自动化压测 ForceBot 体系. ForceBot愿景 1.诞生背景 伴随着京东业务的不断扩张,研发体系的系统也随之增加,各核心系统环环相扣,尤其是强依赖系统,上下游关系等紧密结合,其中一个系统出现瓶颈问题,会影响整个系统链路的处理性能,直接影响用户购物体验. 往年的 618.双 11 大促备战至少提前 3 个月时间

全链路压测自动化实践

背景与意义 境内度假是一个低频.与节假日典型相关的业务,流量在节假日较平日会上涨五到十几倍,会给生产系统带来非常大的风险.因此,在2018年春节前,我们把整个境内度假业务接入了全链路压测,来系统性地评估容量和发现隐患,最终确保了春节期间系统的稳定. 在整个过程中,我们意识到,全链路压测在整个系统稳定性建设中占有核心重要的位置,也是最有效的方案.结合实际业务节假日的频率(基本平均一个月一次),如果能够把它作为稳定性保障的常规手段,我们的系统质量也能够得到很好的保障.同时,为了解决周期常态化压测过程

Http压测工具wrk使用指南

用过了很多压测工具,却一直没找到中意的那款.最近试了wrk感觉不错,写下这份使用指南给自己备忘用,如果能帮到你,那也很好. 安装 wrk支持大多数类UNIX系统,不支持windows.需要操作系统支持LuaJIT和OpenSSL,不过不用担心,大多数类Unix系统都支持.安装wrk非常简单,只要从github上下载wrk源码,在项目路径下执行make命令即可. git clone https://github.com/wg/wrk make make之后,会在项目路径下生成可执行文件wrk,随后

jmeter命令行模式运行,实时获取压测结果

jmeter命令行模式运行,实时获取压测结果 jmeter很小,很快,使用方便,可以在界面运行,可以命令行运行.简单介绍下命令行运行的方式: sh jmeter.sh -n -t my-script.jmx -R 10.6.5.31,10.6.5.35,10.6.5.36,10.6.5.37,10.6.5.72 -l 8.jtl 上面一条命令应该可以满足大部分需求. -n:使用命令行模式运行 -t:指定要运行的jmx脚本 -R:指定使用那些slave节点压测 -l:压测记录保存在哪里 使用-R指

几款常用压测工具使用小结

ab ab是apache自带的压力测试工具,使用起来非常方便. 安装 如果安装了apache, 那么ab已经安装好了,如果不想安装apache的话,可以通过以下方式安装ab # ubuntu sudo apt-get install apache2-utils # centos yum -y install httpd-tools 压测 在压测前,需要关注几个选项,通过 ab -help 查看 Options are: -n requests 要执行的请求次数 -c concurrency 并发

wrk 压测工具

安装 安装命令 git clone https://github.com/wg/wrk ll cd wrk/ ll make ll cp wrk /usr/local/sbin/ 帮助 wrk 使用方法: wrk <选项> <被测HTTP服务的URL> Options: -c, --connections <N> 跟服务器建立并保持的TCP连接数量 -d, --duration <T> 压测时间 -t, --threads <N> 使用多少个线程

【接口】接口压测性能分析及调优建议

常见的互联网架构中,一般都能看到spring+mybatis+mysql+redis搭配的身影,在我所服务的公司亦是如此.一般来说,应用内部的接口都是直接调用的,所谓的面向接口编程,应用间的调用直接调或者通过类似dubbo之类的服务框架来执行,数据格式往往采用json,即统一也方便各数据间做转换和取值,缓存一般使用redis或memcached,存储一些对象或json格式的字符串.对外提供的接口,一般都需要进行压力测试,以便估算其性能,并为后续的调优提供指导方向,以下接口便是在压测过程中出现的各

有赞全链路压测实战

一.前言 有赞致力于成为商家服务领域里最被信任的引领者,因为被信任,所有我们更需要为商家保驾护航,保障系统的稳定性.有赞从去年开始通过全链路压测,模拟大促真实流量,串联线上全部系统,让核心系统同时达到流量峰值: 验证大促峰值流量下系统稳定性 容量规划 进行强弱依赖的划分 降级.报警.容灾.限流等演练 …通过全链路压测这一手段,对线上系统进行最真实的大促演练,获取系统在大压力时的表现情况,进而准确评估线上整个系统集群的性能和容量水平,不辜负百万商家的信任. 有赞对于性能测试主要有线下单系统单接口.

Docker+JMeter+InfluxDB+Grafana从容器内部发起压测

1.自由定制JMeter镜像: Dockerfile文件: FROM java:8# 基础镜像 MAINTAINER yangjianliang <[email protected]># 作者 ENV http_proxy ""ENV https_proxy "" RUN mkdir /test && \ chmod -R 777 /test# 创建/test目录,用于存放jmx脚本.jtl结果文件.html测试报告文件 ENV JMET