Amazon MQ (ActiveMQ)在大消息上性能不佳

Question

我们正在从IBMMQ迁移到Amazon MQ，至少我们希望这样做。问题是Amazon MQ在使用JMS生产者将大消息放入队列时，与IBMMQ相比，性能不佳。

关于IBM MQ，所有消息都是持久的，系统是高可用的，而Amazon MQ是多AZ的。

如果我们将这种大小的XML文件放入IBMMQ（2个cpu和8GB RAM HA实例），我们有这样的性能：

256 KB = 15ms
4,6 MB = 125ms
9,3 MB = 141ms 
18,7 MB = 218ms
37,4 MB = 628ms
74,8 MB = 1463ms

如果我们将相同的文件放在Amazon MQ（mq. m5.2x⃣=8 CPU和32 GB RAM）或ActiveMQ上，我们会有这样的性能：

256 KB = 967ms
4,6 MB = 1024ms
9,3 MB = 1828ms 
18,7 MB = 3550ms
37,4 MB = 8900ms
74,8 MB = 14405ms

我们还看到，IBM MQ在向队列发送消息和从队列获取消息时具有相同的响应时间，而Amazon MQ在获取消息方面非常快（例如，只需1ms），但发送速度非常慢。

在Amazon MQ上，我们使用OpenWire协议。我们以Terraform风格使用此配置：

resource "aws_mq_broker" "default" {
  broker_name                = "bernardamazonmqtest"
  deployment_mode            = "ACTIVE_STANDBY_MULTI_AZ"
  engine_type                = "ActiveMQ
  engine_version             =  "5.15.10"
  host_instance_type         =  "mq.m5.2xlarge"
  auto_minor_version_upgrade =  "false"
  apply_immediately          =  "false"
  publicly_accessible        =  "false"
  security_groups            = [aws_security_group.pittensbSG-allow-mq-external.id]
  subnet_ids                 = [aws_subnet.pittensbSN-public-1.id, aws_subnet.pittensbSN-public-3.id]

  logs {
    general = "true"
    audit   = "true"
  }

我们通过POM (Maven)将Java 8与JMS ActiveMQ库结合使用:

<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>activemq-client</artifactId>
    <version>5.15.8</version>
</dependency>
<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>activemq-pool</artifactId>
    <version>5.15.8</version>
</dependency>

在JMS中，我们有这样的Java代码:

private ActiveMQConnectionFactory mqConnectionFactory;
private PooledConnectionFactory mqPooledConnectionFactory;
private Connection connection;
private Session session;
private MessageProducer producer;
private TextMessage textMessage;
private Queue queue;

this.mqConnectionFactory = new ActiveMQConnectionFactory();
this.mqPooledConnectionFactory = new PooledConnectionFactory();
this.mqPooledConnectionFactory.setConnectionFactory(this.mqConnectionFactory);

this.mqConnectionFactory.setBrokerURL("ssl://tag-1.mq.eu-west-1.amazonaws.com:61617");

this.mqPooledConnectionFactory.setMaxConnections(10);

this.connection = mqPooledConnectionFactory.createConnection());
this.connection.start();

this.session = this.connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
this.session.createQueue("ExampleQueue");

this.producer = this.session.createProducer(this.queue);
long startTimeSchrijf = 0;
startTimeWrite= System.currentTimeMillis();
producer.send("XMLFile.xml");  // here we send the files
logger.debug("EXPORTTIJD_PUT - Put to queue takes: " + (System.currentTimeMillis() - startTimeWrite));

// close session, producer and connection after 10 cycles

我们还将性能测试作为AmazonMQ的单个实例运行。但结果是一样的。我们还使用mq.m5.4XL（16 cpu，96 GB RAM）引擎运行了性能测试，但仍然没有改善糟糕的性能。

性能测试配置:我们首先将消息(XML文件)按上述顺序一个接一个地推到一个队列中。我们做5次。5次之后，我们从队列中读取这些消息(XML文件)。我们称之为1周期。

我们一个接一个地运行10个周期，所以我们总共将300个文件推送到队列中，我们从队列中获得了300个文件。

我们并行运行3个测试：一个来自AWS区域伦敦，一个来自AWS区域法兰克福，在不同的VPC中，一个来自法兰克福，在与Amazon MQ代理相同的VPC和相同的子网中。所有客户端都在EC2实例上运行：m4.xlarge.

如果我们仅使用一个VPC运行测试，例如，仅使用与AmazonMQ代理位于同一子网中的本地VPC，则性能会提高，我们得到以下结果：

256 KB = 72ms
4,6 MB = 381ms
9,3 MB = 980ms 
18,7 MB = 2117ms
37,4 MB = 3985ms
74,8 MB = 7781ms

客户端和服务器位于同一子网中，因此我们与防火墙等无关。

也许有人能告诉我哪里出了问题，为什么亚马逊MQ或ActiveMQ的性能如此糟糕？

额外信息:响应时间是在JMS Java应用程序中测量的，Java starttime在producer.send('XML ')之前，endtime在producer.send('XML ')之后。差异是记录的时间。次数是超过300次呼叫的平均次数。< br> IBM MQ服务器位于我们的数据中心，客户端应用程序运行在同一数据中心的服务器上。

额外信息测试：jms应用程序启动创建连接工厂队列会话。然后，它将文件上传到MQ 1乘1。这是一个周期，然后在一个for LU中运行该周期10次，而不打开或关闭会话队列或连接工厂。然后从队列中读取所有60条消息，并将其写入本地驱动器上的文件。然后关闭连接工厂和会话以及生产者/消费者。这是一批。然后我们运行5批。因此，在批处理之间，将重新创建connectionFactory、队列和会话。

响应 Sam：当我也使用与您相同的文件大小执行测试时 Sam 我接近相同的响应时间，我将持久性模式也设置为 （） 之间的 false 值：

500 KB = 30ms (6ms)
1 MB = 50ms (13ms)
2 MB = 100ms (24ms)

我移除了连接池，并将我使用的系统设置为concurrentStoreAndDispatchQueues = " false " broker:MQ . m 5.2 x large和client: m4.xlarge。

但是如果我用更大的文件进行测试，这是响应时间：

256 KB = 72ms
4,6 MB = 381ms
9,3 MB = 980ms 
18,7 MB = 2117ms
37,4 MB = 3985ms
74,8 MB = 7781ms

我有一个非常简单的要求。我有一个系统，它将消息放在队列中，消息由另一个系统从队列中获取，有时同时，有时不，有时在卸载之前，系统上有20或30条消息。这就是为什么我需要一个队列，消息必须是持久的，并且必须是Java JMS实现。

我认为Amazon MQ可能是小文件的解决方案，但对于大文件则不是。我认为我们必须使用性能更好的IBMMQ。但有一点很重要：我只在局域网中的premis上测试了IBM MQ。我们尝试在Amazon上测试IBM MQ，但尚未成功。

Answer 1

我试图重现您正在测试的场景。当我在同一个VPC中运行JMS客户端时，我看到了以下往返延迟——测量生产者发送消息到消费者收到消息的时刻。

2MB - 50ms
1MB - 31ms
500KB - 15ms

我的代码刚刚创建了一个连接和一个会话。我没有使用池连接工厂（事实上，我没有说/怀疑这是原因）。此外，最好将代码精简到最低限度，以便在进行性能测试时建立基线并消除噪音。这样，当您引入其他代码时，您可以轻松查看新代码是否引入了性能问题。我使用了缺省代理配置。

在ActiveMQ中，有一个快速生产者和快速消费者的概念，这意味着，如果消费者可以以与生产者相同的速率处理消息，则代理通过内存将消息从生产者传输到消费者，然后将消息写入磁盘。这是默认行为，由名为conprestStoreAndDispat的代理配置设置控制，该设置为true（默认）

如果使用者无法跟上生产者的步伐，从而成为“慢速”使用者，并且并发StoreAndDispatch 标志设置为 true，则会对性能造成影响。

ActiveMQ 提供了一些咨询主题，您可以订阅这些主题来检测慢速使用者。如果实际上，您检测到使用者比创建者慢，则最好将 concurrentStoreAndDispatch 标志设置为 false 以获得更好的性能。

Answer 2

我没有收到任何回复。我认为这是因为没有解决这个性能问题的方法。Amazon MQ是一种云服务，也许这就是性能如此糟糕的原因。IBMMQ是一种不同的架构，它是基于前提的。

我必须进一步研究ActiveMQ的性能，然后才能知道这个问题的确切原因。