随着微服务盛行,公司的服务端项目也越来越多。单一的接口性能测试并不能准确反映某个服务的总体处理能力,在服务功能划分比较清晰的架构下,对于某一服务的总体性能测试也相对变得简单。下面分享一个对于某个模块对应的服务的N个接口按照固定比例(来源于线上监控)进行性能测试,基于自己写的性能测试框架第二版

场景:该服务3个接口,比例为1:2:3。

这里为了保证请求不被线程共享,我使用了自己的重写的request深度拷贝的方法拷贝HttpRequestBase对象,这里一定要去做处理,不然线程共享会导致mark请求标记失败,一定要多注意一下Serializable接口的实现,不然会导致拷贝MarkRequest对象拷贝失败,request标记会混乱,还有一种办法就是重写MarkRequestclone()方法也行,如果是使用Groovy语言,建议选择后者。

    public static void main(String[] args) {
def argsUtil = new ArgsUtil(args)
def thread = argsUtil.getIntOrdefault(0, 2)
def times = argsUtil.getIntOrdefault(1, 5)
def split = argsUtil.getStringOrdefault(3, "1:2:3").split(":") def base = getBase()
def flow = new Flow(base)
flow.kSearch("测试")
def request1 = FanLibrary.getLastRequest()
flow.getPlatformK(12)
def request2 = FanLibrary.getLastRequest()
flow.getPaperType()
def request3 = FanLibrary.getLastRequest() MarkRequest mark = new MarkRequest() { private static final long serialVersionUID = -2751325651625435073L; String m; @Override
public String mark(HttpRequestBase request) {
request.removeHeaders("requestid");
m = m == null ? RString.getStringWithoutNum(4) : m
String value = "fun_" + m + CONNECTOR + Time.getTimeStamp();
request.addHeader("requestid", value);
return value;
} }; def requests = []
split[0].times {
requests << new RequestThreadTime(request1, times)
}
split[1].times {
requests << new RequestThreadTime(request2, times)
}
split[2].times {
requests << new RequestThreadTime(request3, times)
}
List<HttpRequestBase> res = []
thread.times {
res << requests
} new Concurrent(res, "对于模块**按照比例${split}压测线程数${thread}次数${times}").start() allOver();
}

  • 郑重声明:文章首发于公众号“FunTester”,禁止第三方(腾讯云除外)转载、发表。

技术类文章精选

非技术文章精选

如何对N个接口按比例压测的更多相关文章

  1. 5. 堪比JMeter的.Net压测工具 - Crank 实战篇 - 接口以及场景压测

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

  2. Jmeter实现dubbo接口压测案例

    当前项目中重构了消息服务,需要对消息服务接口做性能压测,评估消息服务的性能情况 通过和开发对接,目前消息服务是通过dubbo接口对内提供服务,所以才有了这边文章的记录 最初的压测这个dubbo接口有三 ...

  3. Jmeter接口压测小思路

    1.压力接口测试分2种:一种是单场景,压一个接口:第二种是混合场景,多个有关联的接口.压测时间,一般场景都运行10-15分钟.如果是疲劳测试,可以压一天或一周,根据实际情况定. 2.压测前要明确压测功 ...

  4. 开发人员必备工具 —— JMeter 压测

    在接口开发完以后,开发人员应该学会对自己的接口先进行压测一下,虽然压测的结果并不一定准确,也不能完全反映真实情况,但是如果有问题的话多少是可以看出的,而且也可以及早做优化,做到心里有底.否则,等测试进 ...

  5. 1. 堪比JMeter的.Net压测工具 - Crank 入门篇

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

  6. 2. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

  7. 3. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识bombardier

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

  8. 4. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识wrk、wrk2

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

  9. 6. 堪比JMeter的.Net压测工具 - Crank 实战篇 - 收集诊断跟踪信息与如何分析瓶颈

    目录 堪比JMeter的.Net压测工具 - Crank 入门篇 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml 堪比JMeter的.Net压测工具 - Crank 进阶篇 ...

随机推荐

  1. HMM(隐马尔科夫)用于中文分词

    隐马尔可夫模型(Hidden Markov Model,HMM)是用来描述一个含有隐含未知参数的马尔可夫过程. 本文阅读了2篇blog,理解其中的意思,附上自己的代码,共同学习. 一.理解隐马尔科夫 ...

  2. localStorage、sessionStorage、cookie的区别

    localStorage: 存储的内容大概20MB 不同浏览器不能共享,但是在同一浏览器的不同窗口中可以共享 永久生效,它的数据是存储的硬盘上,并不会随着页面或者浏览器的关闭而清楚,需手动清除 ses ...

  3. JPA进行insert操作时会首先select吗

    在某个项目中,使用JPA的saveAll方法去批量写入数据时,通过打印sql,发现每次insert前都会先select一次,极大的浪费了写入性能. 分析一下代码,saveAll() @Transact ...

  4. java操作数组的工具类-Arrays

    static int binarySearch(type[] a, type key) 使用二分搜索法来搜索key元素在数组中的索引:若a数组不包括key,返回负数.(该方法必须已按升序排列后调用). ...

  5. Python--day40--复习和回调函数实例

  6. BZOJ 4236 "JOIOJI"(前缀和+map+pair)

    传送门: [1]:BZOJ [2]:洛谷 •题解 定义数组 a,b,c 分别表示 'J' , 'O' , 'I' 的前缀和: 要想使区间 (L,R] 满足条件当且仅当 a[R]-a[L] = b[R] ...

  7. HDU 1540 Tunnel Warfare (线段树)

    Tunnel Warfare Problem Description During the War of Resistance Against Japan, tunnel warfare was ca ...

  8. Spring AOP 源码分析

    一.准备工作 在这里我先简单记录下如何实现一个aop:   AOP:[动态代理] 指在程序运行期间动态的将某段代码切入到指定方法指定位置进行运行的编程方式: 1.导入aop模块:Spring AOP: ...

  9. linux 内核定时器的实现

    为了使用它们, 尽管你不会需要知道内核定时器如何实现, 这个实现是有趣的, 并且值得 看一下它们的内部. 定时器的实现被设计来符合下列要求和假设: 定时器管理必须尽可能简化. 设计应当随着激活的定时器 ...

  10. Kobjects, Ksets 和 Subsystems

    Kobject 是基础的结构, 它保持设备模型在一起. 初始地它被作为一个简单的引用计数, 但是它的责任已随时间增长, 并且因此有了它自己的战场. struct kobject 所处理的任 务和它的支 ...