前言

这个测试主要是测试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秒的情况。