性能测试工具 基于 Jmeter 的轻量级云压测平台的原理与实现 (一):开篇

zyanycall · August 15, 2018 · Last by zlba111 replied at June 18, 2019 · 7931 hits
本帖已被设为精华帖!

希望大家指出我的不足之处。
希望能帮我点上一颗star,多谢多谢。

github:[https://github.com/zyanycall/stressTestPlatform]

背景

云压测平台在测试领域并不是陌生的名词,简单来说就是在网页/移动端执行压测操作,同时压力机是部署在云端。
如压力节点机在云南,那就是云南产生压力,在北京,那就是北京产生压力。
现阶段云压测平台挺多的,我了解到的就有收费的如阿里云的PTS、XMeter,还有一些开源的,如nGrinder、云集微店的TITAN。

云压测平台要解决什么问题

  1. 压测任务和业务的关系:隶属层级。
  2. 压测任务和测试人员的关系:权限管理。
  3. 摒弃繁琐的手工操作,提高效率,完全线上操作。
  4. 实时查看结果:集成监控平台。
  5. 历史压测数据留存:在线测试报告。
  6. 统一压测工具,统一压测标准。

云压测平台为什么要自己实现

收费的就不提了。
开源的各种压测工具,总会面临各种问题:

  1. 脚本语言写的压测内核,创造压力的性能就不够。
  2. 冷门的压测软件,测试结果难以服众。
  3. 软件用的人少,容易出问题和出了问题不好解决。
  4. 热数据图形监控都不好。
  5. 系统较庞大,占用资源较多。
  6. 是否便于推广,真正减轻工作量。

同时,平台实现之后还有好处:

  1. 和其他测试工具/平台做集成对接。
  2. 和其他部门的工具/平台做对接。
  3. 全链路性能测试的起点,公司性能保障的开端。

实现语言及内核

开发语言

其实平台本身使用什么语言开发都可以,但是由于压力内核选择使用了Jmeter,为了要调用Jmeter的API,平台也选择使用Java开发。

Jmeter的优缺点

优点不详述了,最重要的还是顶级项目开源,社区活跃,Java语言性能好和跨平台。

说下缺点,我目前发现的有:

  1. 代码还是庞大冗余,但这一定程度上保证了软件稳定性。
  2. 至少测试报告的核心开发,水平一般(我有实锤,要反驳的别在这吵)。
  3. Jmeter的API设计的一般,调用时较麻烦。
  4. 分布式压测架构存在中心节点瓶颈,总压力上不去。
  5. 用大文件生成测试报告,时间较长。

所以国内已经有余力的公司(阿里)是在改造Jmeter,就是取其精华去其糟粕了。

Jmeter压测启动的方式

  • 脚本执行

平台根据前端的操作,自动拼接出一行可执行的命令,然后在指定服务器上执行这段脚本。
相当于是手工敲的命令平台帮着拼接和回车执行了。
即便是前端来生成测试脚本,也可以先保存成jmx文件,再脚本执行。
特点是平台和Jmeter_Home完全分离,带来的:

  1. 平台代码可以不用Java写了,什么语言写都可以,仅仅是拼装命令。
  2. 毕竟是脚本执行,Jmeter随意切换版本。
  3. 平台和Jmeter可以不部署在同一台服务器上,即不是相同的进程内了。
  4. Jmeter挂掉不影响平台运行。
  • 程序内引用Jmeter的API来压测执行

平台代码直接调用Jmeter的API。
相对脚本执行的实现:

  1. 平台代码需要使用Java来写,毕竟要引入Jmeter的jar包了。
  2. 同样支持各种版本的Jmeter,但是不灵活。
  3. 同平台在一个进程内产生压力,Jmeter如果挂了,平台也危险,因为可以线程产生压力。

对比脚本执行的好处:

  1. 脚本执行得到的返回仅仅是窗口返回数据,太单薄且不稳定。
  2. 可以定制Jmeter功能,比如自实现压测监控数据。
  • 补充
  1. Jmeter成名已久,程序还是很稳定的,至少master主节点我没遇到因为压测导致的崩溃。同时基于JDK的线程启停都很顺畅。
  2. 网上之前有声音说Jmeter 2系列版本性能更优,我认为是有一定依据的,至少代码量没现在这么臃肿,不过我自测的情况是,4版本和2.13版本的压测性能差不多。
  3. 由于Jmeter 3 版本才开始支持测试报告生成,所以我默认使用Jmeter 4 版本的API。
  4. Jmeter的 API 随着版本更新有变化。

我的平台两种方式都支持,当然推荐是引用Jmeter的API方式启动,可配置。

从需求看实现

核心需求

  • 网页/移动端可以启动压测和停止压测。

最最基本的要求了。

  • 压测数据可以在线实时监控。

如果没有在线实时监控,那和Jmeter自身的脚本压测甚至和AB等工具,就没啥区别了。

  • 可能生成测试报告,最好在线查看,最少也要导出查看。

Jmeter 3 开始支持测试报告,这也是选择Jmeter的原因之一。

  • 支持分布式压测

即云压测的基础。

  • 权限管理

权限管理是平台面向全公司/全网的基础。

  • 业务层级展示

压测需要和具体业务有关系,这个关系在平台上要可以设置。

  • 压测热数据实时监控要可控

图形监控的功能要非常丰富,比如放大缩小等。

  • 删除,下载等操作

删除是让系统文件空间可控。下载是移动办公的基础。

  • 分布式节点管理

分布式压测的衍生需求,有了分布式节点管理,能大大减轻手工操作。同时各种提示非常人性化。

抛弃的需求1:在线生成测试脚本

这曾经是我比较纠结的地方。

  1. 测试脚本要适应各种场景,各种协议,至少HTTP(S),TCP协议要有。
  2. 各种协议就要有不同的输入页面。
  3. 需要前端输入压测指标数据,如步长,虚拟用户数等等。
  4. 断言的实现。
  5. 前端录制脚本。

还有很多很多。
阿里的PTS是让在平台上写脚本代码实现最核心的功能包括断言,然后页面录入压测指标数据。
这样做如果遇到复杂的性能测试要求,问题很大:

  1. 调试困难,不解释了,在线调试代码,尤其移动端,画面太美。
  2. 参数化,测试数据关联要怎么破,尤其测试的请求特别多的情况。
  3. 高昂的学习成本,这么复杂的脚本代码我还搞什么工具推广,工具面对的是小白怎么办。

所以我的选择很简单,上传Jmeter的脚本,同时上传参数化文件。
好处不说了,详细的后续会介绍。

抛弃的需求2:在线监控服务器指标

简单来说,就是平台可以实时监控到服务器的网卡,CPU,内存,磁盘,甚至日志等等。
我放弃的原因:

  1. 自研不如直接用开源。
  2. 运维和阿里云都有监控,功能重复。
  3. 自研性价比不高。

其实这个话题很大,比如监控到什么程度才算合格,能否做到智能化监控与测试报告的连接,服务器指标数据和服务器日志的结合展示分析等等。
在没想好怎么做之前,我的选择是抛弃这部分需求,做不好不如不做。

结尾

平台我一直在深度使用,挺好用。
平台代码当前也比较稳定。

平台创造压力的能力和Jmeter的内核相同,无论是单机还是分布式,同样的支持Grafana+InfluxDB。

后续我会慢慢介绍这个平台,当然也可以直接看我的代码,我自认为代码注释,结构等,还是很清晰的。

压测引擎链接:

基于 Jmeter 的轻量级云压测平台的原理与实现 (二):压测引擎

共收到 89 条回复 时间 点赞

赞一个,不过有一条不是很能同意:
高昂的学习成本,这么复杂的脚本代码我还搞什么工具推广,工具面对的是小白怎么办

性能测试要做好,所需要的技能可能比安全测试还要宽、深(可能有些维度上深度会差异较大),这点学习成本,就不用给做性能测试的工程师们省了
平台的好处就是海纳百川,搜集足够多的信息,也能够灵活快速支持分布式压测,这都是很赞的~另外,如果从测试配置和执行、监控结果中挖掘一些基础的分析和调优建议倒是个不错的思路

我是做性能测试,说真的阿里云的PTS和腾讯的WeTest我都用了,但是功能是在太单调了,不能满足实际情况的需求。
所以我们都是自己写Loadrunner脚本和Jmter脚本,然后根据实际情况租用阿里云机器进行压测的,报告都是自己收集整理的,虽然确实繁琐,但是可以应对实际测试过程中的一些突发情况和奇奇怪怪的需求。

槽神 回复

😂 😂 也有道理!
不过平台的初衷之一是让开发等不专业的也可以执行性能测试,我们仅是管理测试脚本,管理权限就好。

zyanycall 回复

其实我比较想要 脚本、报告、数据等信息的管理维护,以及一个可以自动化关联测试的资源监控平台(可以应付绝大数的数据库、服务器、中间件等监控)。

徐汪成 回复

了解了,压测任务确实各有不同,不过只要是使用Jmeter的脚本,都可以上传到这个平台上进行压测。
至少可以做到:

  1. 脚本的统一保存。
  2. 生成Jmeter自带的测试报告,并在线查看。
  3. 通过复制镜像,生成完备的压力节点机,然后配置到平台上,一键启停。

如果你们的测试报告都是自己整理的,那么你们可能需要完备的监控截图,而我的平台监控截图比grafana的清晰了不少,你们可以作为参考。

zyanycall 回复

嗯 我研究研究。

zyanycall 回复

有时间准备拿你的来改造改造。

徐汪成 回复

好的,👍

Author only
zyanycall 回复
### SQL: insert into test_stress_case_file         (         `case_id`,         `slave_id`,         `status`,         `origin_name`,         `file_name`,         `file_md5`,         `add_by`         )         values         (         ?,         ?,         ?,         ?,         ?,         ?,         ?         )
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column 'slave_id' cannot be null
; SQL []; Column 'slave_id' cannot be null; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column 'slave_id' cannot be null
at org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:85)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:73)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:446)
at com.sun.proxy.$Proxy68.insert(Unknown Source)
zyanycall 回复

兄弟 上传不了脚本?

@zyanycall Taurus (Blazemeter reporting services )了解一下. 重复的轮子

小马 回复

重复的轮子无所谓了。你说一个需求我能给你找100个实现的轮子。

我觉得重要的是思想。

徐汪成 回复

额,这种提到issue里吧……然后堆栈完整一点儿。
看错误是比较简单的,数据库字段不能为null。我本地是可以的,当然完整堆栈能看出是什么问题。

小马 回复

外国人的轮子啊……不知道也是基于Jmeter的吗?
我文中写了不少为什么我要再开发一套的原因,要不你参考一下,然后告诉我Taurus (Blazemeter reporting services ) 是不是都满足了。

16Floor has been deleted
Author only

用了大半年的ngrinder,社区几乎死了一样,二次开发也多半集中在数据的展示,进一步较难。
现在在重新回到jmeter,谢谢楼主分享的方案,有启发

cctodd 回复

楼主写的还是不错,代码也比较容易看懂,可以拿过去自己再进行二次开发。
另外,我觉得既然压测的核心已经交给了jmeter,二次开发还是聚焦在数据展示上面比较好,如果能够实现loadrunner那种实时数据、监控资源展示,还有报表分析的能力那就牛逼了。

徐汪成 回复

多谢肯定。
实时监控的开源产品太多了,最近我还发现了一个 :

https://github.com/AsuraTeam/monitor

这方面要考虑的太多,自己实现很难专业。
另外提到的 报表分析 ,如果做出来确实很牛,就像 听云 ,但是到这步就很难开源了, 是可以赚钱的了。

正在用go写jmeter的性能测试平台 向楼主学习一下

@zyanycall 达康书记 首篇没了 第 二 第三篇呢

小马 回复

我以为没人看呢……

最近也在给团队开发这个高并发的性能测试平台,不过我是用Python手写的,并发可上万。可以交流一哈😁

ZEY 回复

如果能开源就好了 让我学习下。
不知道你底层的压测核心用的什么?

zyanycall 回复

持续关注中,期待后续原理和实现的分享 👏

pom文件用哪个?

boe1900 回复

pom.xml 打war包使用 pom-war.xml

zyanycall 回复

大佬,本地windows使用IDEA启动,生成报告会报The JMETER_HOME environment variable is not defined correctly
This environment variable is needed to run this program

boe1900 回复

嗯嗯 , 需要配置一下Jmeter_home 在数据库中配置。

zyanycall 回复


配置了,昨天在mac上跑成功了,win10上不行,执行脚本的时候说环境变量未设置

boe1900 回复

我就是win10啊。
mac成功了,win10不成功,那先检查配置呗……主要是Jmeter_home的路径,目录下是这样的:

zyanycall 回复

可能是我的apache-jmeter-4.0有问题,我换成apache-jmeter-5.0的,然后把pom里的依赖换成5.0就好了

兄弟,linux上mvn package,然后java -jar renren-fast.jar,运行报错

boe1900 回复

你这个问题github上也提了是吧,我在那里回答你。

基于 Jmeter 的轻量级云压测平台的原理与实现 (一):开篇 (改)
大牛,二和三呢?

您好 我用jmeter压测,请求数比较多,中间有出现502 504 500 的错误,我怎么捕获这些呢。本来我想着用python写个结果分析文件,但结果太大了,jmeter3.0能设置只要这些的结果吗

40Floor has been deleted

感谢使用。
第三方的jar包要写到pom文件里,相当于平台加载的三方jar包,然后重启平台使用。
这方面目前没有什么好办法。

请问下您这个性能平台支持dubbo接口的性能测试吗?

zyanycall 回复

大哥 这个怎么执行压测?

zhanglimin 回复

研究一下Jmeter的断言,能对响应码是502 504 500 标记为错误或者成功。

hhh123x 回复

RPC的接口吗?这个没尝试过。
我们平台是Jmeter内核的,如果Jmeter可以测,那平台就可以。

魏海峰 回复

有执行压测的启动按钮。

zyanycall 回复

嗯..用了...也拜读了你的代码... 确实很清晰易懂... 但是有个建议反馈给楼主:
jmeter master和slave之间用的RMI协议进行通讯的,网络开销很大..在进行超大TPS压测时,master的网卡时常会成为瓶颈.及时不成为瓶颈,经过在压测中数次验证, Master*1 Slave*3 架构可以发出的压力一般都是小于 Master *4的... 在实战中,我都是使用多个Master的模式压测的... Master-Slave的基本不用

zyanycall 回复

替您回复下,Jmeter是支持的...

魏海峰 回复

还是被说出来了啊……其实这个坑我也是深有体会的。文中我也提了。

这个坑,属于Jmeter的缺陷,但你的多master的方式也有问题,主要就是测试数据的监控收集和测试报告的整合及生成。
我想的解决方式,应该还是给Jmeter写插件,不要实时发送数据,而是固定间隔发送数据给master。

当然目前我没心急火燎的解决这个问题,因为实际上,master-slave的结构能产生的压力还凑合。
我这边是有数据的,master是1G网卡的情况下,多slave能产生接近8万的TPS压力。
这个压力的数值,已经可以了。
通俗点儿说,这个压力我认为已经满足绝大多数的压力需求了。

这个问题我已经想着呢,会实现。

zyanycall 回复

楼主,M-S模式和多M模式各有优劣吧...我觉得M-S模式还有个问题就是较大TPS,如你所说的8W,跑稳定性测试的时候,比如跑2个小时,会产生巨大无比的JTL文件... 这个文件处理和分析都是噩梦... 而我的多M模式,则结果数据分散在多个M上,目前我是使用自己写的算法将JTL--->JSON,将JTL里每S的数据聚合成JSON数组的一条,大概的数据结构就是: 2018102601<---> PASS:100,FAILED:10,AVG:10MS,TP99:15 ...,一个数十G的JTL产生的JSON文件一般都不超过1MB,然后将各个M的JSON数据合并.
目前我的难点是实时的展示测试数据...

魏海峰 回复

没有呀,我的平台支持不生成css结果文件的,然后监控数据可以直接来我的平台截图呀,这样测试报告不会过于单薄,同时还会有监控。
你这个自己的算法还是不错的,但是还会面对一个问题,就是测试报告的整合。
你自己的算法也是改的Jmeter源码吗还是插件生成的?还是说处理已有的JTL文件?

52Floor has been deleted
zyanycall 回复

嗯. 不生成结果这个思路可以的... 有趋势图和统计之后的数据一般都足够了..
但是楼主这个好像没有那种汇总的数据... 就是 对整个测试做一个采样分析的比如 总平均TPS,TP99,MAX,MIN之类的...
另外就是一个最大的问题就是,很多公司都有诸如dubbo、SAF之类的SOA系统,测试这种类型的需求,需要:引入被测的jar--->调用被测方法--->测试并统计结果...
楼主这种直接CALL API的方式,如果有多人同时使用并测试SOA的话,怎么搞呢?

魏海峰 回复

唉,也是一种取舍吧。
想要十全十美,肯定是要费一番功夫的。
其实性能测试到底目的是什么,这个要想清楚,后续我合计介绍介绍这个。
有些人都不看测试报告的,或者说报告中有什么根本看不明白,看不出来门道。
我们测试人想的,测试报告,什么趋势图,什么统计数据,其实对某些人来说,有了就是“哦”,没有了就是“你这不行呀”。
我们想的周到的,费力实现的,其实除了自己,别人都体会不到。
测试人不能自己把自己玩死,还是要聚焦到能提高自身价值的地方去。

zyanycall 回复

嗯. 内嵌调用API的方式 确实在RPC测试方面有天然的劣势... 这样会导致多个测试需求共用JRE

  1. 可能因需要刷新JRE导致的不定时重启...
  2. 多个需求会频繁上传jar,带来jar冲突之类的问题... 哎... 难...
魏海峰 回复

看来你这一下提了不少的需求啊,总体的数据结果分析+分布式节点的拆分利用。
简单聊聊吧。
数据结果table展示:
当然这个我还没做,因为Jmeter提供的测试报告是包含这些的。
你提的应该是抛弃测试报告的时候,这些聚合数据怎么弄?
我可以给折线图增加这些数据的线啊,Jmeter传统的聚合报告的table展示是有弊端的,因为对比它,折线图不仅能展示趋势,还能包含历史数据,是更优的选择。
目前我没做因为我用不到99%Line等,还因为没人给我提这种需求。

分布式节点的拆分利用:
这个比较复杂了,其实Jmeter自己对这个支持的就不好啊,想一想,如果单独用Jmeter,怎么利用多个slave?还不是要多个master。
我的平台想要展示不同的slave集群的结果,还要基于Jmeter的API之上,其实是有难度的。
这个地方我是有想法的,但是还没验证就不在这里说了。
我的原则是能不改Jmeter的源码就不改,因为它发展的很快,改它源码不合适。
是有想法的,嗯嗯,如果真有这方面的需求,是可以实现的。

魏海峰 回复

是吧,平台上传jar包这种操作,是测试自己掌握的。
不能说平台的管理还搞一堆其他部门的人来染指,那就说不过去了。
你说的包冲突,频繁上传,都是我们测试来掌握的。

测试的jar包要稳定,可以先Jmeter工具自身测试验证后,再到平台上来,所以你说的平台频繁启动刷新JRE,是属于过度使用平台了。

zyanycall 回复

不是的... 使用jmeter测试RPC需求的时候,需要把测试jar和依赖的jar放到JmeterHome\lib\ext下面,可以预见经历若干个测试需求以后,JmeterHome\lib\ext下会有大量重复的jar... 引发jar包冲突...

不过如果想使用一套jmeter环境的话,可以考虑下面的解决方案;

  1. 自定义一个jmeter.properties, 修改search_paths属性,指向某个测试任务专用的路径,可以和参数化文件放在一起;
  2. 启动jmeter时,使用-p参数,用法:-p, --propfile the jmeter property file to use 这样可以防止测试jar污染jmeter环境
魏海峰 回复

嗯嗯。也可以。
我刚刚查了一下测试dubbo的。确实比较复杂。

zyanycall 回复

楼主,经我验证,你的平台目前需要改掉3个地方才能进行RPC脚本的测试;
StressTestFileServiceImpl.java中修改三处:

// 1. 加入 loader声明的全局变量

private static final DynamicClassLoader loader;

// 2. static代码块的最后 加入
loader = AccessController.doPrivileged(
new java.security.PrivilegedAction() {
@Override
public DynamicClassLoader run() {
return new DynamicClassLoader(jars.toArray(new URL[jars.size()]));
}
}
);
// 3. setJmeterProperties()方法开始加入
Thread.currentThread().setContextClassLoader(loader);

以上均经过实测.

魏海峰 回复

这几处代码是我当初没有放进去的。主要是因为最后一行:Thread.currentThread().setContextClassLoader(loader); 这会将当前线程的类加载器换成自定义的。
Jmeter的自己的原有的启动类是需要这个的,为了将lib目录下的jar包的类加载到内存中,但我们平台是不同的,平台的环境里已经存在了绝大部分的类,没必要把lib目录下的所有的jar包都在每一个脚本执行的时候再加载一遍(应该还是占用内存的,即使重复也要来一套,没验证)。

如果你非要追求Jmeter_Home的那种全量的环境,可以使用脚本模式执行,同时外挂influxDB+Grafana监控,这是满足你的需求的。

当前平台还不打算搞的所有的lib包还要重复加载一遍。

zyanycall 回复

嗯嗯... 仅仅给是楼主提下建议... 主要是要测试RPC的需求的话,必须要将RPC接口本身的包引入JMETER环境...

恒温 将本帖设为了精华贴 04 Nov 20:08

其实比如PTS也支持了原生JMeter的压测了,不用担心并发不够的问题,报表也是现成的。XMeter不了解。

xmter核心还是jmeter吧,

魏海峰 回复

有做类似的平台?能否分享?

请教一下,我脚本里使用了BeanShell,Jmeter脚本启动启动可以,但是以代码的方式,会报错,是有什么插件没有装吗?

boe1900 回复

你好,可以到项目的issue里去提一下问题。
需要看一下异常是什么才能确定到底缺什么包。

大佬,目前是以shell方式生成的测试报告,对jmeter不是很熟悉,请问可以java代码的形式生成吗?

boe1900 回复

可以的。
你可以查一下源码中的 org.apache.jmeter.report.dashboard.ReportGenerator 类, 是通过它生成报告的。
调用如下:
ReportGenerator generator = new ReportGenerator(reportFile, null);
generator.generate();

👍 关注中,期待二三,希望不会断掉

这个平台能否部署到centos系统呢?

jojotester 回复

可以的。

为啥生成的报告是csv格式的?

xulei 回复

你好,主要是因为我使用jtl文件生成测试报告会遇到异常,我看是Jmeter4.0里强制写的判断。

同时还有一些附带的原因:

  1. 相同的请求数量,jtl文件比CSV的文件大。
  2. CSV文件的内容比jtl文件的丰富,有一些指标是仅支持CSV文件的(jmeter.properties文件中有说明,不详细贴了)。

可能我这方面了解的还不多,如果你有好的方式,让Jmeter4 使用jtl 来生成测试报告,一定要知道我一下如何做……对平台的结果展示很有用。

zyanycall 回复

//String reportPathDir = csvPath.substring(0, csvPath.lastIndexOf("."));
代码这句有问题,下载报告时报错,不应该只截取到点

xulei 回复

我本地执行是正常的。
建议把这种必现问题提到issue上吧,然后请详细说明一下报的异常是什么,问题现象是什么,多谢了。

因为我初步判断这里应该不存在兼容性问题。那么我的环境是OK的,想不到为什么你那里会失败。
提issue吧。

😂 在生成报告的时候,也遇到了 The JMETER_HOME environment variable is not defined correctly
跟楼上那位一样的问题,JMETER_HOME D:\software\apache-jmeter-4.0 没问题

jojotester 回复

😂 😂
建议直接使用Jmeter的脚本命令先试一下生成报告。
生成测试报告是建立在Jmeter本身的功能上的。
同时注意运行平台的用户和安装平台的用户权限是否一致。

这个异常信息是Jmeter自己打印的,我自己的异常信息都是中文大白话的……。

定时任务那块能讲解下吗?是如何定时执行测试用例吗?

jojotester 回复

定时的估计是用spring-task或者quartz,设置定时规则,另起线程启动测试就行了。

jojotester 回复

目前的定时压测是使用本身Jmeter脚本的自带功能:

其他定时任务是执行平台的方法,需要个人对平台根据需求二次开发,和性能测试关系就不太大了。

84Floor has been deleted
Author only
zyanycall · #86 · November 26, 2018 作者
Author only
87Floor has been deleted
Author only
小马 回复

这个人不是我,是拿我的东西给自己宣传了。
我QQ邮箱是 : 444104595@qq.com

小马 回复

还不支持。
不过你这种方式真的是不错的,借助docker解决client部署的问题,甚至能解决slave的重复利用问题(需要测试验证不能贸然使用)。
目前平台还仅仅是支持slave的事先部署(也可以用docker部署Jmeter),没有docker的这种脚本的自动批量部署和销毁(平台虽然没有但是使用者可以自己实现,然后将数据插入到数据库的slave表中即可)。

平台目前的职责非常单一清晰,就是把脚本能页面执行+页面监控+生成测试报告。脚本的页面执行包含了分布式情况下的执行。分布式环境的其实并不在平台的核心职责之内。

zyanycall 回复

还有一点 就是我看你的Report 是Jmeter自带的实际是性能方向的报告.
能支持接口测试方向的报告么? 比如ant 那种的 或者allure 等其他report框架那种的.

小马 回复

额,这是一个性能测试平台,不负责接口测试的事情。
接口测试的报告还是接口测试平台来做。

其实平台缺少的是一个调试脚本的手段方式,并且这个需求场景越来越频繁。

依次说一下吧。
ant 主要是卡在脚本执行结果文件格式上了。 ant需要jtl,但是测试报告需要CSV,有冲突。
allure 等的是接口测试平台的职责,作为调试手段不如ant了。

MASTER_JMETER_USE_SCRIPT_KEY

TRUE or FALSE
FALSE时,在服务器进程内启动JMeter,是什么意思?

调试中遇到个问题,因为在测试计划中有个自用的JAR包,只能用本地JMETER_HOME这种方式

jojotester 回复

服务器进程内启动JMeter,意思是使用Jmeter的API来启动脚本。

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 13 Dec 14:44

学习了,感谢楼主分享!!我们公司也准备搭建这样的一个平台~~

98Floor has been deleted
Author only
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up