性能文章>测试Activemq artemis队列生产消费ack场景优化版本>

测试Activemq artemis队列生产消费ack场景优化版本原创

316988

 

 

前言

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

架构设计

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

名词说明

生产10000数据总共耗时

是指客户端从开始发送第一条到第1万条数据总共的耗时时间,单位毫秒。

消费10000数据总共耗时

是指服务端从开始消费第一条到第1万条数据总共的耗时时间,单位毫秒。

最后单条消息消耗需要

是指最后单条消息消耗需要耗费的时间,通常队列的消费先进先出,所以最后一条的消费耗时代表木桶的最高那块,也是耗时最久的,一开始的耗时几乎都趋近于几百毫秒。

异步接收

是指用当前配置的线程消费,完了把队列的消息放到本地缓存队列。对于消费端的线程池消费队列则是配置成如下方式:

new LinkedBlockingQueue<>());

异步消费

是指只用当前配置的线程消费,当消费不过来的时候在amq里面等待。对于消费端的线程池消费队列则是配置成如下方式:

new SynchronousQueue(), new ThreadPoolExecutor.CallerRunsPolicy());

测试代码

其余代码参考上一篇笔记

@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 11B mac 6 12+2 636ms centos 8 8+2 467ms 373ms centos 8 8+2 490ms 404ms
5000 11B mac 6 12+2 503ms centos 8 8+2 634ms 503ms centos 8 8+2 661ms 533ms
5000 11B mac 6 12+2 888ms centos 8 8+2 726ms 378ms centos 8 8+2 849ms 509ms
5000 11B mac 6 12+2 611ms centos 8 8+2 424ms 111ms mac 6 12+2 520ms 200ms
5000 11B mac 6 12+2 694ms centos 8 8+2 338ms 88ms mac 6 12+2 605ms 362ms
5000 11B mac 6 12+2 939ms centos 8 8+2 735ms 152ms mac 6 12+2 953ms 369ms
5000 1KB mac 6 12+2 846ms centos 8 8+2 580ms 208ms centos 8 8+2 582ms 231ms
5000 1KB mac 6 12+2 703ms centos 8 8+2 781ms 510ms centos 8 8+2 822ms 563ms
5000 2KB mac 6 12+2 914ms centos 8 8+2 961ms 533ms centos 8 8+2 997ms 603ms
5000 2KB mac 6 12+2 895ms centos 8 8+2 712ms 291ms centos 8 8+2 711ms 334ms
5000 3KB mac 6 12+2 1106ms centos 8 8+2 797ms 194ms centos 8 8+2 799ms 209ms
5000 3KB mac 6 12+2 1216ms centos 8 8+2 911ms 194ms centos 8 8+2 908ms 199ms

小结:这里测试正常情况不考虑处理情况,只考虑队列的传输情况,数据量小看着好像问题不大,没有2KB以下5K数据没什么问题。

异步消费

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
5000 11B mac 6 12+2 821ms centos 8 8+2 742ms 402ms centos 8 8+2 768ms 433ms
5000 11B mac 6 12+2 664ms centos 8 8+2 834ms 614ms centos 8 8+2 884ms 673ms
5000 11B mac 6 12+2 759ms centos 8 8+2 1105ms 783ms centos 8 8+2 1200ms 882ms
5000 11B mac 6 12+2 600ms centos 8 8+2 680ms 561ms mac 6 12+2 666ms 435ms
5000 11B mac 6 12+2 577ms centos 8 8+2 674ms 528ms mac 6 12+2 688ms 369ms
5000 11B mac 6 12+2 720ms centos 8 8+2 963ms 718ms mac 6 12+2 992ms 578ms
5000 1KB mac 6 12+2 723ms centos 8 8+2 787ms 464ms centos 8 8+2 815ms 508ms
5000 1KB mac 6 12+2 780ms centos 8 8+2 791ms 416ms centos 8 8+2 832ms 464ms
5000 2KB mac 6 12+2 1652ms centos 8 8+2 1380ms 127ms centos 8 8+2 1388ms 143ms
5000 2KB mac 6 12+2 1292ms centos 8 8+2 1033ms 158ms centos 8 8+2 1036ms 166ms
5000 3KB mac 6 12+2 1594ms centos 8 8+2 1380ms 176ms centos 8 8+2 1387ms 186ms
5000 3KB mac 6 12+2 1513ms centos 8 8+2 1242ms 193ms centos 8 8+2 1253ms 208ms
5000 1KB mac 6 12+2 1169ms centos 8 8+2 1025ms 1025ms mac 6 12+2 1914ms 1076ms
5000 1KB mac 6 12+2 915ms centos 8 8+2 727ms 367ms mac 6 12+2 1589ms 1185ms
5000 1KB mac 6 12+2 879ms centos 8 8+2 752ms 298ms mac 6 12+2 1844ms 1357ms
5000 2KB mac 6 12+2 946ms centos 8 8+2 706ms 112ms mac 6 12+2 2303ms 1669ms
5000 2KB mac 6 12+2 1116ms centos 8 8+2 870ms 127ms mac 6 12+2 2817ms 2037ms
5000 3KB mac 6 12+2 1499ms centos 8 8+2 1228ms 95ms mac 6 12+2 4040ms 2869ms
5000 3KB mac 6 12+2 1648ms centos 8 8+2 1390ms 203ms mac 6 12+2 4053ms 2769ms

小结:这边的消费场景,主要还是模拟数据消费的情况,两个维度,数据很小的情况,还有1KB,2KB,3KB的情况。之前测试,换了两台服务器来测试ack场景发现用本地当回复的效果很差,因为本地的环境影响会导致消耗的时间大于服务器的时间,感觉没有参考价值,所以只关注都是服务器的场景。

1万数据测试

异步接收

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
10000 11B mac 6 12+2 929ms centos 8 8+2 841ms 460ms centos 8 8+2 894ms 532ms
10000 11B mac 6 12+2 805ms centos 8 8+2 767ms 482ms centos 8 8+2 883ms 623ms
10000 11B mac 6 12+2 1013ms centos 8 8+2 1005ms 692ms centos 8 8+2 1047ms 761ms
10000 11B mac 6 12+2 831ms centos 8 8+2 913ms 622ms centos 8 8+2 1077ms 788ms
10000 11B mac 6 12+2 877ms centos 8 8+2 725ms 133ms mac 6 12+2 1122ms 527ms
10000 11B mac 6 12+2 860ms centos 8 8+2 767ms 245ms mac 6 12+2 1277ms 747ms
10000 11B mac 6 12+2 857ms centos 8 8+2 854ms 340ms mac 6 12+2 1058ms 552ms
10000 1KB mac 6 12+2 1049ms centos 8 8+2 813ms 193ms centos 8 8+2 862ms 267ms
10000 1KB mac 6 12+2 1241ms centos 8 8+2 1066ms 353ms centos 8 8+2 1112ms 448ms
10000 2KB mac 6 12+2 1701ms centos 8 8+2 1418ms 221ms centos 8 8+2 1521ms 345ms
10000 2KB mac 6 12+2 1595ms centos 8 8+2 1449ms 252ms centos 8 8+2 1466ms 272ms
10000 3KB mac 6 12+2 2310ms centos 8 8+2 2031ms 161ms centos 8 8+2 2030ms 165ms
10000 3KB mac 6 12+2 2647ms centos 8 8+2 2447ms 253ms centos 8 8+2 2461ms 272ms

小结:这里是消费接收场景,测试结果来看,有点客户端发送不过来的场景,客户端使用14个线程开始发送,从消息延时来看基本不存在消息堆积太久的情况,消息堆积了就马上消费了。

异步消费

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

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
10000 11B mac 6 12+2 953ms centos 8 8+2 1336ms 832ms centos 8 8+2 1418ms 915ms
10000 11B mac 6 12+2 847ms centos 8 8+2 1322ms 1031ms centos 8 8+2 1411ms 1130ms
10000 11B mac 6 12+2 1038ms centos 8 8+2 1419ms 862ms centos 8 8+2 1524ms 975ms
10000 11B mac 6 12+2 820ms centos 8 8+2 1665ms 1297ms mac 6 12+2 1736ms 1224ms
10000 11B mac 6 12+2 945ms centos 8 8+2 1812ms 1399ms mac 6 12+2 1802ms 1222ms
10000 11B mac 6 12+2 1241ms centos 8 8+2 1812ms 1043ms mac 6 12+2 1246ms 878ms
10000 1KB mac 6 12+2 1145ms centos 8 8+2 1540ms 891ms centos 8 8+2 1710ms 1064ms
10000 1KB mac 6 12+2 1090ms centos 8 8+2 1778ms 1060ms centos 8 8+2 1882ms 1168ms
10000 2KB mac 6 12+2 1609ms centos 8 8+2 1899ms 664ms centos 8 8+2 1970ms 740ms
10000 2KB mac 6 12+2 1693ms centos 8 8+2 1855ms 558ms centos 8 8+2 1882ms 616ms
10000 3KB mac 6 12+2 2340ms centos 8 8+2 2002ms 58ms centos 8 8+2 1999ms 61ms
10000 3KB mac 6 12+2 2390ms centos 8 8+2 2086ms 62ms centos 8 8+2 2087ms 65ms
10000 5KB mac 6 12+2 3444ms centos 8 8+2 3209ms 97ms centos 8 8+2 3203ms 102ms
10000 1KB mac 6 12+2 1240ms centos 8 8+2 1284ms 407ms mac 6 12+2 3228ms 2335ms
10000 1KB mac 6 12+2 1498ms centos 8 8+2 1603ms 449ms mac 6 12+2 2973ms 1796ms
10000 2KB mac 6 12+2 1678ms centos 8 8+2 2209ms 980ms mac 6 12+2 4600ms 3242ms
10000 2KB mac 6 12+2 1568ms centos 8 8+2 2559ms 1462ms mac 6 12+2 4954ms 3733ms
10000 3KB mac 6 12+2 1977ms centos 8 8+2 1724ms 190ms mac 6 12+2 6714ms 5044ms
10000 3KB mac 6 12+2 2363ms centos 8 8+2 2147ms 242ms mac 6 12+2 6409ms 4433ms

小结:从结果来看,这里是消费场景,按照惯性,发送1KB数据到第一个topic应该也在1秒才对,但是这里超过了1秒,因为这里包含了再次回复ack的时间所以实际时间会比单个的要久,从结果来看2KB以内都基本没什么问题,本身数据量也比较小。

3万数据测试

异步接收

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
30000 11B mac 6 12+2 1534ms centos 8 8+2 2313ms 1298ms centos 8 8+2 2576ms 1572ms
30000 11B mac 6 12+2 1623ms centos 8 8+2 2606ms 1671ms centos 8 8+2 2656ms 1725ms
30000 11B mac 6 12+2 1781ms centos 8 8+2 2599ms 1369ms centos 8 8+2 2732ms 1514ms
30000 11B mac 6 12+2 1656ms centos 8 8+2 2769ms 1630ms centos 8 8+2 3150ms 2018ms
30000 11B mac 6 12+2 1716ms centos 8 8+2 2445ms 1041ms mac 6 12+2 3600ms 2194ms
30000 11B mac 6 12+2 1561ms centos 8 8+2 1829ms 775ms mac 6 12+2 3377ms 2327ms
30000 11B mac 6 12+2 1447ms centos 8 8+2 2164ms 1032ms mac 6 12+2 3246ms 2144ms
30000 1KB mac 6 12+2 1534ms centos 8 8+2 2313ms 1298ms centos 8 8+2 2576ms 1572ms
30000 1KB mac 6 12+2 3283ms centos 8 8+2 6025ms 3201ms centos 8 8+2 6131ms 3379ms
30000 1KB mac 6 12+2 3054ms centos 8 8+2 3983ms 1365ms centos 8 8+2 4015ms 1400msW
30000 2KB mac 6 12+2 5273ms centos 8 8+2 5080ms 240ms centos 8 8+2 5089ms 254ms
30000 2KB mac 6 12+2 4741ms centos 8 8+2 4855ms 570ms centos 8 8+2 4997ms 735ms
30000 3KB mac 6 12+2 7926ms centos 8 8+2 7756ms 256ms centos 8 8+2 7813ms 317ms
30000 3KB mac 6 12+2 6407ms centos 8 8+2 6262ms 308ms centos 8 8+2 6275ms 326ms

小结:从结果来看,忽略本地的场景,因为本地的影响因素太大了,还是看单个服务之间得消息转发场景,3w数量上去了,感觉消费有点吃紧了,小数据都有点消耗不过来,存在堆积的情况,当提高数据的发送量,发送耗时也上去了,消耗耗时也上去了,但消息的延时感觉差不多,可能网络抖动就有点差别,时好时坏,但是总的来说感觉差不多。这里还有一个奇怪的点,越大发送越耗时,所以消息延时越低,因为发送还没有消耗的快。

异步消费

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
30000 11B mac 6 12+2 2128ms centos 8 8+2 4104ms 2520ms centos 8 8+2 4440ms 2861ms
30000 11B mac 6 12+2 1596ms centos 8 8+2 4268ms 3256ms centos 8 8+2 4678ms 3667ms
30000 11B mac 6 12+2 1618ms centos 8 8+2 3452ms 2299ms mac 6 12+2 3699ms 2374ms
30000 11B mac 6 12+2 1933ms centos 8 8+2 4345ms 3046ms mac 6 12+2 6470ms 5017ms
30000 11B mac 6 12+2 1502ms centos 8 8+2 3489ms 2647ms mac 6 12+2 3940ms 2925ms
30000 1KB mac 6 12+2 2729ms centos 8 8+2 5602ms 3365ms centos 8 8+2 5902ms 3669ms
30000 1KB mac 6 12+2 3031ms centos 8 8+2 5430ms 3125ms centos 8 8+2 5864ms 3574ms
30000 2KB mac 6 12+2 4171ms centos 8 8+2 6283ms 2515ms centos 8 8+2 6572ms 2810ms
30000 2KB mac 6 12+2 5100ms centos 8 8+2 6985ms 2324ms centos 8 8+2 7129ms 2495ms
30000 3KB mac 6 12+2 6359ms centos 8 8+2 6868ms 999ms centos 8 8+2 7027ms 1188ms
30000 3KB mac 6 12+2 7544ms centos 8 8+2 7765ms 627ms centos 8 8+2 7905ms 855ms
30000 3KB mac 6 12+2 8018ms centos 8 8+2 8420ms 910ms centos 8 8+2 8476ms 973ms
30000 1KB mac 6 12+2 2405ms centos 8 8+2 4812ms 2776ms mac 6 12+2 9549ms 7448ms
30000 1KB mac 6 12+2 2456ms centos 8 8+2 3988ms 1893ms mac 6 12+2 8224ms 6063ms
30000 2KB mac 6 12+2 3865ms centos 8 8+2 5290ms 1785ms mac 6 12+2 14877ms 11314ms
30000 2KB mac 6 12+2 4737ms centos 8 8+2 5702ms 1383ms mac 6 12+2 14778ms 10403ms
30000 3KB mac 6 12+2 6505ms centos 8 8+2 6294ms 209ms mac 6 12+2 21294ms 15078ms
30000 3KB mac 6 12+2 6212ms centos 8 8+2 6015ms 236ms mac 6 12+2 21646ms 15780ms
30000 2KB mac 6 12+2 4280ms centos 8 8+2 5401ms 1461ms centos-236 8 8+2 5422ms 1487ms
30000 2KB mac 6 12+2 4175ms centos 8 8+2 5746ms 1921ms centos-236 8 8+2 5842ms 2025ms
30000 1KB mac 6 12+2 2963ms centos 8 8+2 4395ms 1734ms centos-236 8 8+2 4383ms 1747ms
30000 1KB mac 6 12+2 2848ms centos 8 8+2 4329ms 1776ms centos-236 8 8+2 4314ms 1782ms

小结:从结果来看,数据很小的时候,发送很快,消耗不过来存在消息堆积的情况,消息延时会有2~3秒,但是当数据变成2KB发送就开始吃力了,消息延迟就开始减小,另外测试了在另一台机器启动另一个服务测试消费场景,不知道是否网络的原因,居然会比一台机器两个topic的还要快,同样的数量和大小。

备注:centos-236是临时从新在另一台服务器启动了一个服务从消息从本地到centos 再到-> centos-236完成一整个流程,从结果来看,跟一个服务内部两个topic的效果几乎差不多。

5万数据测试

异步接收

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
50000 11B mac 6 12+2 25ms centos 8 8+2 4247ms 2704ms centos 8 8+2 4448ms 2928ms
50000 11B mac 6 12+2 49ms centos 8 8+2 4101ms 2654ms centos 8 8+2 4253ms 2851ms
50000 11B mac 6 12+2 60ms centos 8 8+2 5105ms 3003ms centos 8 8+2 6157ms 4064ms
50000 11B mac 6 12+2 2050ms centos 8 8+2 4397ms 2885ms centos 8 8+2 4555ms 3048ms
50000 11B mac 6 12+2 2461ms centos 8 8+2 6208ms 4479ms centos 8 8+2 6368ms 4715ms
50000 11B mac 6 12+2 2777ms centos 8 8+2 3866ms 1618ms centos 8 8+2 4008ms 1774ms
50000 11B mac 6 12+2 2506ms centos 8 8+2 4335ms 2378ms centos 8 8+2 4597ms 2696ms
50000 11B mac 6 12+2 2474ms centos 8 8+2 5352ms 3353ms mac 6 12+2 7933ms 5852ms
50000 11B mac 6 12+2 2649ms centos 8 8+2 4247ms 1957ms mac 6 12+2 6064ms 3777ms
50000 11B mac 6 12+2 2285ms centos 8 8+2 3399ms 1566ms mac 6 12+2 6006ms 4165ms
50000 11B mac 6 12+2 2120ms centos 8 8+2 3445ms 1657ms mac 6 12+2 5289ms 3501ms
50000 1KB mac 6 12+2 5824ms centos 8 8+2 6621ms 1234ms centos 8 8+2 6824ms 1444ms
50000 1KB mac 6 12+2 5561ms centos 8 8+2 6932ms 1810ms centos 8 8+2 7289ms 2172ms
50000 2KB mac 6 12+2 8567ms centos 8 8+2 8511ms 371ms centos 8 8+2 8593ms 457ms
50000 2KB mac 6 12+2 8024ms centos 8 8+2 8082ms 519ms centos 8 8+2 8113ms 680ms
50000 3KB mac 6 12+2 11907ms centos 8 8+2 11823ms 379ms centos 8 8+2 11875ms 435ms
50000 3KB mac 6 12+2 10729ms centos 8 8+2 10350ms 202ms centos 8 8+2 10352ms 233ms
50000 3KB mac 6 12+2 29ms centos 8 8+2 10593ms 115ms centos 8 8+2 10602ms 180ms
50000 3KB mac 6 12+2 26ms centos 8 8+2 11151ms 188ms centos 8 8+2 11216ms 463ms

小结:从结果来看,当数据量小的情况下,本地是否缓存差别不大,感觉网络抖动对于时间的波动还是有点影响的,当发送数量很大的时候,数据大小还是不影响消耗的,但是当发送的数据变成1KB开始消耗不过来了,1KB的消耗延时还是有点消耗吃力,但是不存在发送时间大于消耗的情况,但是到了2KB就发现发送吃力了,消耗变得轻松,消息延迟开始趋近于正常的消息传递时间。

备注:这里多加了两条本地缓存的数据,看着跟本地不缓存的消耗的时间跟缓存的时间差多少,实际感觉差不多

异步消费

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

数据量 数据大小 是否处理消息 是否二次投递消息 客户端类型 客户端是否缓存发送消息 cpu 线程数 发送耗时 服务器端类型 cpu 线程数 接收耗时 最后消息延时 服务器端类型 cpu 线程数 接收耗时 最后消息延时
50000 11B mac 6 12+2 2083ms centos 8 8+2 9263ms 7614ms centos 8 8+2 9634ms 8340ms
50000 11B mac 6 12+2 3216ms centos 8 8+2 7933ms 5177ms centos 8 8+2 8586ms 5840ms
50000 11B mac 6 12+2 2086ms centos 8 8+2 8101ms 6373ms centos 8 8+2 8794ms 7069ms
50000 11B mac 6 12+2 1857ms mac 6 12+2 12410ms 10930ms mac 6 12+2 12622ms 277ms
50000 11B mac 6 12+2 1905ms centos 8 8+2 7354ms 5958ms mac 6 12+2 7950ms 6399ms
50000 11B mac 6 12+2 1984ms centos 8 8+2 7316ms 5931ms mac 6 12+2 7567ms 6023ms
50000 11B mac 6 12+2 1866ms centos 8 8+2 6693ms 5338ms mac 6 12+2 6946ms 5436ms
50000 1KB mac 6 12+2 4796ms centos 8 8+2 9720ms 5394ms centos 8 8+2 10327ms 6011ms
50000 1KB mac 6 12+2 4597ms centos 8 8+2 9709ms 5620ms centos 8 8+2 10347ms 6274ms
50000 2KB mac 6 12+2 8121ms centos 8 8+2 10933ms 3254ms centos 8 8+2 11175ms 3548ms
50000 2KB mac 6 12+2 8840ms centos 8 8+2 11064ms 2683ms centos 8 8+2 11293ms 2930ms
50000 3KB mac 6 12+2 12068ms centos 8 8+2 12617ms 1008ms centos 8 8+2 12722ms 1148ms
50000 3KB mac 6 12+2 12373ms centos 8 8+2 13145ms 1370ms centos 8 8+2 13255ms 1507ms

小结:从结果来看,整个发送和消耗都挺饱和,不存在发送不过来消耗等待的情况,发送和消耗都有一定的延迟,当消息很小的时候,发送是很快的,消耗不过来,存在很久的延迟,但是当消息的字节数达到1KB及其以上的时候发送开始吃力,消耗压力减少,延迟开始降低。

总结

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

这次主要模拟处理消息然后回复ack的场景,从结果来看,如果不考虑消息消费耗时的情况1秒1万的数据量在服务端消费端是没什么问题的,数据的大小只会影响发送端不会影响消耗端。

当考虑到数据的大小情况消息体的大小的情况,发送不超过1KB也还好,当超过1KB就开始吃力了。存在消息延时1秒的情况。

点赞收藏
查拉图斯特拉说

让世界因你而不同

请先登录,查看8条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
8
8