在之前的性能测试中,用到了延迟队列java.util.concurrent.DelayQueue
的功能下单延迟 10s 撤单性能测试,其实也是简单使用到了基本的 API,演示如下DelayQueue 基础功能演示。在对 Java & Go 各种队列做性能对比测试的规划里面也没法这个延迟队列算进来。当时感觉这个队列设计到很多排序,而且用的数组实现的队列,加上了java.util.concurrent.ArrayBlockingQueue
队列的性能资料,所以以为延迟队列性能比较差,放弃了做对比测试。
最近在看了goreplay
的项目资料后,发现这个真流量回放还是很有搞头的,就是根据请求的时间戳进行判断是否立即发出请求。这个针对不同的压测场景中,更加优秀的匹配了线上流量的波动(对波动场景效果最佳)。也能发现更多存在的性能瓶颈和风险项。文章源自玩技e族-https://www.playezu.com/192314.html
所以呢,我打算再次发挥抄能力,把 goreplay 这个功能抄下来,就使用java.util.concurrent.DelayQueue
作为消息队列实现类。文章源自玩技e族-https://www.playezu.com/192314.html
结论
java.util.concurrent.Delayed
自身性能百万级别 QPS,足够满足接口性能测试 QPS,目前 FunTester 设计的目标还是单进程满足 50 万 QPS。使用习惯上跟之前的队列测试结果一致,队列积累的数量越小 QPS 越高,线程数越多 QPS 会保持一个极限,单进程的 QPS 会降低。不确定是否跟我自身硬件瓶颈相关。以后有机会再服务器上再进行一波测试,毕竟服务器配置是我自己配置的 8 倍有余。文章源自玩技e族-https://www.playezu.com/192314.html
测试用例
测试用例沿用了之前的静态压测模型中的,固定线程模式。跟之前测试 Java&Go 的保持一致。有兴趣的可以翻一翻:文章源自玩技e族-https://www.playezu.com/192314.html
- Java&Go 高性能队列之 LinkedBlockingQueue 性能测试
- Java&Go 高性能队列之 Disruptor 性能测试
- Java&Go 高性能队列之 channel 性能测试
可延迟对象
这里需要创建一个可延迟对象,需要继承一个java.util.concurrent.Delayed
接口,具体实现如下:文章源自玩技e族-https://www.playezu.com/192314.html
/**
* 日志对象
*/
static class FunTesterDelay implements Delayed {
long timestamp
String str
FunTesterDelay() {
this.timestamp = 5
this.str = DEFAULT_STRING
}
@Override
long getDelay(@NotNull TimeUnit unit) {
return timestamp - Time.getTimeStamp()
}
@Override
int compareTo(@NotNull Delayed o) {
return 0
}
}
测试用例
使用静态模型线程模式。文章源自玩技e族-https://www.playezu.com/192314.html
static int thread = 20
static int times = 100000
static def delays = new DelayQueue<FunTesterDelay>()
public static void main(String[] args) {
RUNUP_TIME = 0
new Concurrent(new FunTester(),thread,"DelayQueue性能测试").start()
}
private static class FunTester extends FixedThread {
FunTester() {
super(null, times, true)
}
@Override
protected void doing() throws Exception {
delays.add(new FunTesterDelay())
}
@Override
FunTester clone() {
return new FunTester()
}
}
测试结果
添加
这里简单测试了添加功能,方法com.funtest.groovytest.Update.FunTesterDelay#compareTo
默认返回了 0,就是不排序了。文章源自玩技e族-https://www.playezu.com/192314.html
线程 | 次数(万) | QPS(万) | 单线程 QPS(万) |
---|---|---|---|
1 | 10 | 54 | 54 |
5 | 10 | 194 | 38 |
10 | 10 | 325 | 32 |
20 | 10 | 450 | 22 |
50 | 10 | 315 | 6 |
100 | 10 | 333 | 3 |
100 | 20 | 258 | 2.5 |
200 | 10 | 283 | 1.4 |
添加删除
这里直接先添加后删除,简单粗暴,快速看结果。这里的 1 个 QPS,实际相当于 2 个 QPS。文章源自玩技e族-https://www.playezu.com/192314.html
线程 | 次数(万) | QPS(万) | 单线程 QPS(万) |
---|---|---|---|
1 | 10 | 48 | 48 |
5 | 10 | 123 | 24 |
10 | 10 | 197 | 19 |
20 | 10 | 246 | 12 |
50 | 10 | 284 | 5 |
100 | 10 | 255 | 2.5 |
100 | 20 | 283 | 2.8 |
200 | 10 | 283 | 1.4 |
看来跟之前测试过的队列结论都差不多。保持队列不要太长,线程数增加会导致单线程效率变低,不过总得的 QPS 依然保持在 250 万 ~ 300 万之间。足够满足性能测试需求了。文章源自玩技e族-https://www.playezu.com/192314.html
FunTester 原创专题集锦文章源自玩技e族-https://www.playezu.com/192314.html
- 性能测试专题
- Java、Groovy、Go、Python
- 单测&白盒
- FunTester 社群风采
- 测试理论鸡汤
- 接口功能测试专题
- FunTester 视频专题
- 案例分享:方案、BUG、爬虫
- UI 自动化专题
- 测试工具专题
阅读原文,跳转我的仓库地址
软件功能测试流程图
评论