Мы переходим с IBM MQ на Amazon MQ, по крайней мере, мы бы хотели это сделать. Проблема в том, что Amazon MQ имеет низкую производительность при использовании JMS-производителя для помещения большого сообщения в очередь по сравнению с IBM MQ.
Все сообщения являются постоянными, и система имеет высокий уровень доступности для IBM MQ, а Amazon MQ multi AZ.
Если мы поместим этот размер файлов XML в IBM MQ (экземпляр с 2 ЦП и 8 ГБ ОЗУ ОЗУ), мы получим такую производительность:
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.2xlarge = 8 ЦП и 32 ГБ ОЗУ) или 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 очень быстро получает сообщение (например, занимает всего 1 мс), но очень медленно отправляет.
В 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"
}
Мы используем Java 8 с библиотекой JMS ActiveMQ через POM (Maven):
<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.4xlarge (16 процессоров, 96 ГБ ОЗУ), но все еще не улучшили плохую производительность.
Конфигурация теста производительности: сначала мы выводим сообщения sh (XML файлов) по очереди выше по очереди. Мы делаем это 5 раз. Через 5 раз мы читаем эти сообщения (XML файлы) из очереди. Мы называем это 1 циклом.
Мы запускаем 10 циклов один за другим, поэтому всего мы выдвинули 300 файлов в очередь и получили 300 файлов из очереди.
Мы запускаем 3 параллельные тесты: один из AWS Region Londen, один из AWS Region Frankfurt в другом VP C и 1 из Франкфурта в том же VP C, что и брокер Amazon MQ, и в том же su bnet , Все клиенты работают на экземпляре EC2: m4.xlarge.
Если мы запускаем тест только с одним VP C, например, только с локальным VP C, который находится в том же su bnet, что и У брокера AmazonMQ улучшается производительность, и мы получаем следующие результаты:
256 KB = 72ms
4,6 MB = 381ms
9,3 MB = 980ms
18,7 MB = 2117ms
37,4 MB = 3985ms
74,8 MB = 7781ms
Клиент и сервер находятся в одном и том же su bnet, поэтому мы не имеем ничего общего с межсетевым экраном и т. Д. c.
Может, кто-нибудь подскажет, что не так и почему у нас такая ужасная производительность с Amazon MQ или ActiveMQ?
дополнительная информация: время отклика измеряется в приложении JMS Java с Java временем запуска перед производителем.send ('XML') и только в конечное время сразу после производителя.send ('XML'). Разница - это записанное время. Среднее время выполнения вызовов превышает 300.
Сервер IBM MQ находится в нашем центре обработки данных, а клиентское приложение выполняется на сервере в том же центре обработки данных.
проверка дополнительной информации: приложение jms начинает создавать очереди connectionFactory сессий. Затем он загружает файлы в MQ 1 на 1. Это цикл, затем он запускает этот цикл 10 раз в течение одного дня без открытия или закрытия очередей сеансов или соединений. Затем все 60 сообщений считываются из очереди и записываются в файлы на локальном диске. Затем он закрывает фабрику соединений, сеанс и производителя / потребителя. Это одна партия. Затем мы запускаем 5 партий. Таким образом, между партиями восстанавливаются connectionFactory, очередь, сеанс.
В ответ Сэму: Когда я также выполняю тест с файлами того же размера, что и у Сэма, я приближаюсь к тому же времени отклика, я устанавливаю постоянство Режим также имеет значение false между ():
500 KB = 30ms (6ms)
1 MB = 50ms (13ms)
2 MB = 100ms (24ms)
Я удалил пул соединений и установил concurrentStoreAndDispatchQueues = "false" Система, которую я использовал, брокер: mq.m5.2xlarge и клиент: 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 может быть решением для небольших файлов, но для больших файлов это не так. Я думаю, что мы должны использовать IBM MQ для этого случая, который имеет лучшую производительность. Но одна важная вещь: я тестировал IBM MQ только в нашей локальной сети. Мы пытались протестировать IBM MQ на Amazon, но пока не смогли.