延迟队列DelayQueue性能测试

在之前的性能测试中,用到了延迟队列java.util.concurrent.DelayQueue的功能下单延迟10s撤单性能测试,其实也是简单使用到了基本的API,演示如下DelayQueue基础功能演示。在对Java & Go各种队列做性能对比测试的规划里面也没法这个延迟队列算进来。当时感觉这个队列设计到很多排序,而且用的数组实现的队列,加上了java.util.concurrent.ArrayBlockingQueue队列的性能资料,所以以为延迟队列性能比较差,放弃了做对比测试。

最近在看了goreplay的项目资料后,发现这个真流量回放还是很有搞头的,就是根据请求的时间戳进行判断是否立即发出请求。这个针对不同的压测场景中,更加优秀的匹配了线上流量的波动(对波动场景效果最佳)。也能发现更多存在的性能瓶颈和风险项。

所以呢,我打算再次发挥抄能力,把goreplay这个功能抄下来,就使用java.util.concurrent.DelayQueue作为消息队列实现类。

结论

java.util.concurrent.Delayed自身性能百万级别QPS,足够满足接口性能测试QPS,目前FunTester设计的目标还是单进程满足50万QPS。使用习惯上跟之前的队列测试结果一致,队列积累的数量越小QPS越高,线程数越多QPS会保持一个极限,单进程的QPS会降低。不确定是否跟我自身硬件瓶颈相关。以后有机会再服务器上再进行一波测试,毕竟服务器配置是我自己配置的8倍有余。

测试用例

测试用例沿用了之前的静态压测模型中的,固定线程模式。跟之前测试Java&Go的保持一致。有兴趣的可以翻一翻:

可延迟对象

这里需要创建一个可延迟对象,需要继承一个java.util.concurrent.Delayed接口,具体实现如下:

    /**
     * 日志对象
     */
    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
        }
    }

测试用例

使用静态模型线程模式。


    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,就是不排序了。

线程 次数(万) 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。

线程 次数(万) 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万之间。足够满足性能测试需求了。

FunTester原创专题集锦 - 性能测试专题 - Java、Groovy、Go、Python - 单测&白盒 - FunTester社群风采 - 测试理论鸡汤 - 接口功能测试专题 - FunTester视频专题 - 案例分享:方案、BUG、爬虫 - UI自动化专题 - 测试工具专题

阅读原文,跳转我的仓库地址