lettinhgo什么意思 queue队列

在之前的性能测试中，用到了延迟队列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&Go高性能队列之LinkedBlockingQueue性能测试
Java&Go高性能队列之Disruptor性能测试
Java&Go高性能队列之channel性能测试

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

/*** 日志对象*/static class FunTesterDelay implements Delayed {long timestampString strFunTesterDelay() {this.timestamp = 5this.str = DEFAULT_STRING}@Overridelong getDelay(@NotNull TimeUnit unit) {return timestamp - Time.getTimeStamp()}@Overrideint compareTo(@NotNull Delayed o) {return 0}}

测试用例使用静态模型线程模式。

static int thread = 20static int times = 100000static def delays = new DelayQueue()public static void main(String[] args) {RUNUP_TIME = 0new Concurrent(new FunTester(),thread,"DelayQueue性能测试").start()}private static class FunTester extends FixedThread {FunTester() {super(null, times, true)}@Overrideprotected void doing() throws Exception {delays.add(new FunTesterDelay())}@OverrideFunTester 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
【lettinhgo什么意思 queue队列】看来跟之前测试过的队列结论都差不多。保持队列不要太长，线程数增加会导致单线程效率变低，不过总得的QPS依然保持在250万 ~ 300万之间。足够满足性能测试需求了。

特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。