RABBITMQ Performance Test

background:

Online environment, an accident, the initial location is RABBITMQ server.

By grasping the packet discovery, there are multiple apps using the same RABBITMQ server. And the way multiple apps use RABBITMQ is different. The following two ways are found:

1. Produce one message at a time, opening and closing the channel once

2. Each produce a message, opening and closing connection once, opening and closing the channel once.

This method of use is one of the points we suspect, in addition to the suspicion that there are:

1. Configuration Issues for RABBITMQ cluster

2. Hardware issues with RABBITMQ server (reflected in increased io_wait of disk, increase in TCP connections)

3. RABBITMQ's own problems?

4. Network jitter and network latency?

Because there are more possibilities, it is necessary to do a comprehensive evaluation and positioning.

Some tasks are assigned to it and operational tracking. My side is mainly responsible for the evaluation of client usage methods

Goal:

1. Confirm that the use of the two methods of use (see above) will cause bottlenecks?

2. Confirm the two methods of use, under what circumstances will be problematic? Will it be possible to reproduce it in a few hundred minutes?

Theoretically, RABBITMQ documents, as well as packet capture data: Each message switch once connection must be the least efficient.

Imagine, each message body, need to establish and close a TCP connection, the middle also doped with AMQP control messages, how waste resources!!!!

The results of the simple assessment are as follows:

Method description	Peak Message Volume	Parameters	Note
Share a connection, each message switches one channel at a time.	2000msg/s	1 Threads, no consumer	Using native RABBITMQ, native Java client
Each message switch once connection	200msg/s	1 Threads, no consumer	Using native RABBITMQ, native Java client

The result above is a simple test result.

There was a problem when trying to mix and use two modes to access the local RABBITMQ. The problem is also very strange, when one method of the process starts, the other one will sockettimeout.

Later had to find a RABBITMQ server in the test environment.

Then Google took a turn, the original has a jmeter-rabbitmq-plugin. It's so handsome. The function is not all oneself wants, does not matter, changes Bai. Code See: Https://github.com/lykm02/JMeter-Rabbit-AMQP. (i updated the Maven build method and some jar version information on branch support_maven_xx)

Put in the JMeter, you can use the JMeter to press.

The conclusion is that the use of connection does affect the interior of the RABBITMQ, causing other connections to the same RABBITMQ to be affected.

The specific work principle, because involves rabbitmq the source code, does not have the thorough research at present.

RABBITMQ Performance Test