测试Activemq artemis队列生产消费ack

于 2023-08-28 18:07:29 发布
阅读量108 收藏
点赞数
文章标签： java-activemq activemq java 压力测试
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_33816117/article/details/132544528
版权

文章目录

前言

这个测试主要是测试ActiveMQ Artemis消息中间件，因为业务的特殊性，需要测试消息一来一回算一次，单次统计结果可以参考上一篇测试的结果。

架构设计

还是采用客户端和服务端再到客户端的形式，毕竟只用本地很容易卡影响结果，消息先从本地发送到服务器，然后从服务器发送回本地，完成一次消息完整的流程。也测试了服务器到服务器的场景，但是是单个服务所以相当于左手换右手的感觉。

测试代码

其余代码参考上一篇笔记

@Log4j2
@Component
public class ListenerAndSendMq {

    private static final String UPDATE_API_STRATEGY_AND_BASKET = "localhost";

    public static AtomicInteger atomicInteger = new AtomicInteger();
    public static AtomicInteger atomicIntegerSingle = new AtomicInteger();
    AtomicReference<Long> start = new AtomicReference<>(0L);
    int cores = Runtime.getRuntime().availableProcessors();

    ThreadPoolExecutor threadPoolExecutor
            = new ThreadPoolExecutor(cores + 2, cores + 2, 60, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>());
//            new ArrayBlockingQueue(10), new BlockPolicy());
//              new SynchronousQueue(), new BlockPolicy());
//            new SynchronousQueue(), new ThreadPoolExecutor.CallerRunsPolicy());

    public static int count = 50000;

    @PostConstruct
    public void receiveApiStrategyCache() {

        log.info("====================receiveApiStrategyCache========cores{}============", cores);
        Messenger.subscribe(UPDATE_API_STRATEGY_AND_BASKET+"/ack", new MessageConsumer() {
            @Override
            public void onMessage(final Message<?> message) {
                if (message instanceof BinaryMessage) {
                    try {
                        final BinaryMessage msg = (BinaryMessage) message;
                        final MessageHeader header = msg.getHeader();
                        final String payload = new String(msg.getPayload());
                        long timestamp = header.getTimestamp();
                        if (atomicIntegerSingle.get() == 0) {
                            start.set(System.nanoTime());
                        }
                        if (atomicIntegerSingle.incrementAndGet() >= count) {
                            log.info("offset:{}ms", System.currentTimeMillis() - timestamp);
                            log.info("消费{}数据总共耗时：{}ms", count, TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start.get()));
                        }
                        sendMessage(UPDATE_API_STRATEGY_AND_BASKET, payload, header);
                    } catch (Exception e) {
                        log.error(e);
                    }
                }
            }

            @Override
            public void onError(final Message<?> message) {
                log.error("from TOPIC {} error: {}", message.getHeader().getTopic(), message.getPayload());
            }
        });
        Messenger.subscribe(UPDATE_API_STRATEGY_AND_BASKET+"/ack/multiple", new MessageConsumer() {
            @Override
            public void onMessage(final Message<?> message) {
                if (message instanceof BinaryMessage) {
                    threadPoolExecutor.execute(() -> {
                        final BinaryMessage msg = (BinaryMessage) message;
                        final MessageHeader header = msg.getHeader();
                        final String payload = new String(msg.getPayload());
                        long timestamp = header.getTimestamp();
                        if (atomicInteger.get() == 0) {
                            start.set(System.nanoTime());
                        }
                        if (atomicInteger.incrementAndGet() >= count) {
                            log.info("offset:{}ms", System.currentTimeMillis() - timestamp);
                            log.info("消费{}数据总共耗时：{}ms", count, TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start.get()));
                        }
                        sendMessage(UPDATE_API_STRATEGY_AND_BASKET+"/multiple", payload, header);
                    });
                }
            }

            @Override
            public void onError(final Message<?> message) {
                log.error("from TOPIC {} error: {}", message.getHeader().getTopic(), message.getPayload());
            }
        });
    }

    public void sendMessage(String topic, String world, MessageHeader oldHeader) {
        final MessageHeader header = new MessageHeader(topic, oldHeader.getId(), oldHeader.getTimestamp());
        final BinaryMessage message = new BinaryMessage(header, world.getBytes());
        try {
            Messenger.send(message);
        } catch (final IOException e) {
            log.error("error", e);
        }
    }

}

5000数据测试

异步接收

只考虑接收的情况，假定队列消费很顺畅的情况，不存在处理消息导致消费耗时的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
5000否是mac是612+2636mscentos88+2467ms373mscentos88+2490ms404ms
5000否是mac是612+2503mscentos88+2634ms503mscentos88+2661ms533ms
5000否是mac是612+2888mscentos88+2726ms378mscentos88+2849ms509ms
5000否是mac否612+2611mscentos88+2424ms111msmac612+2520ms200ms
5000否是mac否612+2694mscentos88+2338ms88msmac612+2605ms362ms
5000否是mac否612+2939mscentos88+2735ms152msmac612+2953ms369ms
异步消费

这里主要是边处理消息和边统计的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
5000是是mac否612+2821mscentos88+2742ms402mscentos88+2768ms433ms
5000是是mac否612+2664mscentos88+2834ms614mscentos88+2884ms673ms
5000是是mac否612+2759mscentos88+21105ms783mscentos88+21200ms882ms
5000是是mac否612+2600mscentos88+2680ms561msmac612+2666ms435ms
5000是是mac否612+2577mscentos88+2674ms528msmac612+2688ms369ms
5000是是mac否612+2720mscentos88+2963ms718msmac612+2992ms578ms

1万数据测试

异步接收

只考虑接收的情况，假定队列消费很顺畅的情况，不存在处理消息导致消费耗时的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
10000否是mac是612+2929mscentos88+2841ms460mscentos88+2894ms532ms
10000否是mac是612+2805mscentos88+2767ms482mscentos88+2883ms623ms
10000否是mac是612+21013mscentos88+21005ms692mscentos88+21047ms761ms
10000否是mac是612+2831mscentos88+2913ms622mscentos88+21077ms788ms
10000否是mac否612+2877mscentos88+2725ms133msmac612+21122ms527ms
10000否是mac否612+2860mscentos88+2767ms245msmac612+21277ms747ms
10000否是mac否612+2857mscentos88+2854ms340msmac612+21058ms552ms
异步消费

这里主要是边处理消息和边统计的情况。

注意这里第一阶段1w的数据已经超过1秒了，是因为包含了转发消息的时间，也就是ack

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
10000是是mac否612+2953mscentos88+21336ms832mscentos88+21418ms915ms
10000是是mac否612+2847mscentos88+21322ms1031mscentos88+21411ms1130ms
10000是是mac否612+21038mscentos88+21419ms862mscentos88+21524ms975ms
10000是是mac否612+2820mscentos88+21665ms1297msmac612+21736ms1224ms
10000是是mac否612+2945mscentos88+21812ms1399msmac612+21802ms1222ms
10000是是mac否612+21241mscentos88+21812ms1043msmac612+21246ms878ms

3万数据测试

异步接收

只考虑接收的情况，假定队列消费很顺畅的情况，不存在处理消息导致消费耗时的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
30000否是mac是612+21534mscentos88+22313ms1298mscentos88+22576ms1572ms
30000否是mac是612+21623mscentos88+22606ms1671mscentos88+22656ms1725ms
30000否是mac是612+21781mscentos88+22599ms1369mscentos88+22732ms1514ms
30000否是mac是612+21656mscentos88+22769ms1630mscentos88+23150ms2018ms
30000否是mac否612+21716mscentos88+22445ms1041msmac612+23600ms2194ms
30000否是mac否612+21561mscentos88+21829ms775msmac612+23377ms2327ms
30000否是mac否612+21447mscentos88+22164ms1032msmac612+23246ms2144ms
异步消费

这里主要是边处理消息和边统计的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
30000是是mac否612+22128mscentos88+24104ms2520mscentos88+24440ms2861ms
30000是是mac否612+21596mscentos88+24268ms3256mscentos88+24678ms3667ms
30000是是mac否612+21618mscentos88+23452ms2299msmac612+23699ms2374ms
30000是是mac否612+21933mscentos88+24345ms3046msmac612+26470ms5017ms
30000是是mac否612+21502mscentos88+23489ms2647msmac612+23940ms2925ms

5万数据测试

异步接收

只考虑接收的情况，假定队列消费很顺畅的情况，不存在处理消息导致消费耗时的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
50000否是mac是612+225mscentos88+24247ms2704mscentos88+24448ms2928ms
50000否是mac是612+249mscentos88+24101ms2654mscentos88+24253ms2851ms
50000否是mac是612+260mscentos88+25105ms3003mscentos88+26157ms4064ms
50000否是mac否612+22050mscentos88+24397ms2885mscentos88+24555ms3048ms
50000否是mac否612+22461mscentos88+26208ms4479mscentos88+26368ms4715ms
50000否是mac否612+22777mscentos88+23866ms1618mscentos88+24008ms1774ms
50000否是mac否612+22506mscentos88+24335ms2378mscentos88+24597ms2696ms
50000否是mac否612+22474mscentos88+25352ms3353msmac612+27933ms5852ms
50000否是mac否612+22649mscentos88+24247ms1957msmac612+26064ms3777ms
50000否是mac否612+22285mscentos88+23399ms1566msmac612+26006ms4165ms
50000否是mac否612+22120mscentos88+23445ms1657msmac612+25289ms3501ms
异步消费

这里主要是边处理消息和边统计的情况。

数据量是否处理消息是否二次投递消息客户端类型客户端是否缓存发送消息cpu线程数发送耗时服务器端类型cpu线程数接收耗时最后消息延时服务器端类型cpu线程数接收耗时最后消息延时
50000是是mac否612+22083mscentos88+29263ms7614mscentos88+29634ms8340ms
50000是是mac否612+23216mscentos88+27933ms5177mscentos88+28586ms5840ms
50000是是mac否612+22086mscentos88+28101ms6373mscentos88+28794ms7069ms
50000是是mac否612+21857msmac612+212410ms10930msmac612+212622ms277ms
50000是是mac否612+21905mscentos88+27354ms5958msmac612+27950ms6399ms
50000是是mac否612+21984mscentos88+27316ms5931msmac612+27567ms6023ms
50000是是mac否612+21866mscentos88+26693ms5338msmac612+26946ms5436ms

发送大小

1KB
生产10000数据总共耗时：937ms
offset:244ms
消费10000数据总共耗时：717ms
2KB
生产10000数据总共耗时：1552ms
offset:106ms
消费10000数据总共耗时：1248ms
3KB
生产10000数据总共耗时：1929ms
offset:170ms
消费10000数据总共耗时：1642ms
5KB
生产10000数据总共耗时：3000ms
offset:203ms
消费10000数据总共耗时：2753ms
8KB
生产10000数据总共耗时：4484ms
offset:187ms
消费10000数据总共耗时：4220ms
10KB
生产10000数据总共耗时：5501ms
offset:190ms
消费10000数据总共耗时：5239ms
20KB
生产10000数据总共耗时：11443ms
offset:207ms
消费10000数据总共耗时：11190ms
100KB
30KB
生产10000数据总共耗时：17048ms
offset:228ms
消费10000数据总共耗时：16810ms

总结

之前的一篇测试结果发现单个消息1秒一万多条消息是没有压力的，超过了可能产生堆积的情况，最明显的区别就是发送时间和处理时间。

这次主要模拟处理消息然后回复ack的场景，发现大打折扣，消息处理只能达到5千多点。毕竟是一来一回这样的情况，在原来的基础上又发了一次。

另外发现当消息的大小不超过1kb的时候是符合上面的测试结果的，但是超过了1kb，发送也会很耗时。

查拉图斯特拉talk
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
Apache ActiveMQ Artemis.pdf
04-07
消息队列现在是服务器编程最重要的中间件，开源消息队列多种多样，的rabbitMQ、rockerMQ，这个文档是activeMQ的框架Artemis的编程指南，可以下载学习
Centos7安装mqtt服务器（apache-artemis）从入门到应用
weixin_45923343的博客
02-27 4697
保姆级教程，理论+实践 整合全网所有资料
测试Activemq artemis队列生产消费
最新发布
qq_33816117的博客
08-24 363
在考虑消费情况时，1万数据量可以轻松处理，没有任何压力，但这只是单机测试的结果，只能作为参考。如果消费没有耗时，3万数据量也可以处理，但前提是所有消费都堆积在缓存中。因此，在实际应用中，需要根据具体场景和需求来确定数据量的大小和处理方式。同时，还需要考虑系统的其他性能指标，如响应时间、错误率等来综合评估系统的性能表现。
window下安装Apache ActiveMQ Artemis消息队列, 搭建MQTT服务器
ywb201314的专栏
02-20 594
Apache ActiveMQ™是最流行的开源，多协议，基于Java的消息服务器。它支持行业标准协议，因此用户可以通过广泛的语言和平台选择。可以使用C，C ++，Python，.Net等连接。使用无处不在的AMQP协议集成您的多平台应用程序。使用STOMP通过websockets 在Web应用程序之间交换消息。使用MQTT管理您的IoT设备。支持您现有的JMS基础架构及其他。ActiveMQ提供强大的功能和灵活性，以支持任何消息传递用例。在ActiveMQ官网“经典”的5.x Broker。
ActiveMQ-为什么需要消息中间件？
weixin_30552811的博客
12-26 111
消息中间件的优势 UNIX的进程间通信就开始运用消息队列技术，一个进程将数据写入某个特定的队列中，其它进程可以读取队列中的数据，从而实现异步通信。对于如今的分布式系统，消息队列已经演变为独立的消息中间件产品，相比于RPC同步通信的方式来说有几个明显的优势： 低耦合，不管是程序还是模块之间，使用消息中间件进行间接通信。 消息的顺序性，消息队列可以保证消息的先进先出。 消息可靠传输，持久化...
嵌入式消息队列artemis
weixin_43964005的博客
07-19 941
1.依赖引入 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- springboot
activemq-artemis-dynatrace-plugin:ActiveMQ Artemis经纪人流程的自定义Dynatrace JMX插件
05-03
Dynatrace的ActiveMQ Artemis插件关于经纪人流程的自定义 插件。Artemis概述插件该插件提供常规的代理统计信息，例如地址内存使用率，连接/用户数，总消息数，总消息添加/确认率。 Artemis Queues插件这提供了详细的...
activemq-artemis-docker:ActiveMQ Artemis项目的Dockerfile
05-10
1.什么是ActiveMQ Artemis？ 是一个开源项目，用于构建多协议，可嵌入，非常高性能的集群异步消息传递系统。 Apache ActiveMQ Artemis是面向消息的中间件（MoM）的示例。 2.标签和Dockerfile链接 基于Debian 基于...
tasks:Spring Boot和ActiveMQ Artemis的生产者消费者微服务教程
03-21
任务Spring Boot和ActiveMQ Artemis的生产者消费者微服务教程。涵盖的主题Sprint Boot子休息区ApiSpring启动批处理SSL连接JMS（Java消息服务） Swagger UI用于可视化API错误处理基本认证POJO <-> DTO的映射器记录...
ActiveMQ消息传送机制以及ACK机制详解
01-27
消息的生命周期一般包括：生产者发送、Broker存储、消费者消费和确认（ACK）、Broker删除消息。在某些情况下，如消息过期或存储空间不足，消息会被提前删除。 二、ActiveMQ ACK机制 ACK（Acknowledgement）机制是...
Artemis 高性能的MQ
10-08
讲述高性能MQ框架Apache Artemis，深入浅出的讲解，层层递进的剖析，推荐阅读
Artemis集群（18）
MIT的博客
09-05 5027
    Artemis集群允许将Artemis服务组组合在一起，便于共享消息的负载处理。集群中每个活动节点都是一个活动的Artemis服务，它管理自己的消息并处理自己的连接。集群中的每个节点都通过broker.xml配置文件来声明与其他节点关系，从而形成集群。当一个集群节点连接到另一节点时，通过在内部创建一个core bridge来建立他们之间的连接。不需要为每个节点都声明一个明确的bridge，...
分布式系统基础-消息队列之ActiveMQ
Ron.Zheng
10-18 1300
ActiveMQ是J2EE中 JMS消息通信规范的一个实现，也是目前还在活跃和发展的最古老的第一代MQ，自从2004年成熟以后就迅速传播开来，经过多年的发展，逐步奠定了它在Java/J2EE圈子里的开源霸主地位，可谓生生不息。ActiveMQ除了作为独立的消息中间件使用，还经常在某些ESB （Enterprise Service Bus）产品中作为总线基础设施（ Bus Infrastructur
spring boot 使用activeMQ实现消息队列简单应用
weixin_35768716的博客
03-01 543
1 简介 1.1 什么是ActiveMQ ActiveMQ 是 Apache 出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个 完全支持 JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现,尽管 JMS 规范出台已经是很久的事 情了,但是 JMS 在当今的 J2EE 应用中间仍然扮演着特殊的地位。 1.2 JMS介绍 1....
（1）Artemis简介
热门推荐
MIT的博客
08-27 1万+
1.简介     Artemis是通过基于netty的非堵塞IO架构开发的，拥有出色的性能。由jboss捐献的HornetQ的衍生版本，可能作为下一代ActiveMQ的存在。     选择Artemis的原因开源、高可用性、Java编写、高性能的日志保证持久化消息像非持久化消息一样拥有出色的表现、功能齐全、简洁的设计、灵活的集群可以通过不可靠的全球网络创建地理上分布的集群。     Arte...
Artemis资源管理配置与定时消息（10）
MIT的博客
09-04 1205
资源管理配置     Artemis拥有自己的资源管理器，用于处理JTA事务的生命周期。启动事务时，将通知资源管理器并保留事务及其当前状态的记录。在某些情况下，可能出现启动事务但后来被遗忘了。也许客户端异常，再也没有重连。如果发生这种情况，那么事务将无限期的等待。     Artemis为了处理这类问题，通过配置可以扫描并回滚它找到的任何旧事务。默认值为3000000毫秒（5分钟），即删除任何...
Artemis保证消息的发送和提交（12）
MIT的博客
09-04 1181
事务实现     当使用Artemis提交或回滚事务时，提交或回滚的请求将发送到服务器，并且将阻塞客户端，直到从服务器收到提交或回滚的生效响应。     当在服务器上收到提交或回滚时，它将被提交到日志，并且根据参数journal-sync-transactional的值为true，服务器将确保在发送响应到客户端之前将提交或回滚操作持久化存储。如果此参数的值为false，直到某个时间将响应发送到...
Artemis逾期消息（14）
MIT的博客
09-05 1045
    可以在发送消息时设置消息的存活时间。Artemis将不会投递超过存活时间的消息。如果消息在达到存活时间后还未被投递，服务器可以丢弃该消息。可以为Artemis分配一个逾期地址，以便在消息逾期后从队列中删除并发送到逾期地址。多个不同的队列可以绑定到同一个逾期地址，这些逾期消息可以被消费用于进一步的检测。 CORE API     使用Artemis CORE API客户端可以直接在消息里...
（4）Artemis支持的协议
MIT的博客
08-28 2223
目录   1.AMQP 1.1 消息转换 1.2 拦截和更改消息 1.3 AMQP广播地址（TOPIC） 1.4 AMPQ事务消息 1.5 AMQP消息投递调度 2.MQTT 2.1 留用（retain）消息 2.2 will消息 2.3 debug日志 2.4 通配符（wild）订阅 3.STOMP 3.1 将STOMP目的地映射到地址和队列 3.2 STOMP心跳...
activemq 生产者的ack机制
05-20
ActiveMQ 生产者的 ACK（确认）机制是指，当生产者发送消息到 ActiveMQ 服务端时，服务端会给生产者返回一个 ACK 确认消息，表示已经成功接收到消息。一般情况下，ACK 机制会分为两种类型： 1. 自动 ACK： 生产者...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

查拉图斯特拉talk

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值