performance of version 3.6.12 downgrade

[baoyonglei]

I made a test of performance between 3.5.6 and 3.6.12 on linux， the result shows the performance of 3.6.12 become worse than 3.5.6.

The test created 1000 productors and 500 consumers, while each productor sending a message every second. The size of msg is 1024 bytes. With version 3.5.6, it works well, but at version 3.6.12, a lot of "timeout" errros happens, like "queue.declare"、"connect".

BTW, the rabbitmqctl command also become slower, and cpu utility become higher.
the same environment.
3.5.6：
rabbitmqctl status: 0.712s, 0.834s, 0.750s, 0.780s, 0.635s
rabbitmqctl list_queues: 0.962s, 0.670s, 0.735s, 0.841s, 0.900s
rabbitmqctl list_connection: 1.464s, 0.684s, 0.686s, 1.515s, 1.019s
cpu: less than 10%

3.6.12：
rabbitmqctl status：2.217s，2.112s，1.565s，2.266s，2.349s
rabbitmqctl list_queues 529队列：2.058s，2.304s，3.679s，3.018s，1.905s
rabbitmqctl list_connection 519: 1.817s, 1.740s, 1.945s, 2.686s, 1.661s
cpu: 20 ~ 30

Is it true that performance of the latest release become worse?

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. This assumes two things:

1. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team)
2. We have a certain amount of information to work with

We get at least a dozen of questions through various venues every single day, often quite light on details.
At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because of that questions, investigations, root cause analysis, discussions of potential features are all considered to be mailing list material by our team. Please post this to rabbitmq-users.

Getting all the details necessary to reproduce an issue, make a conclusion or even form a hypothesis about what's happening can take a fair amount of time. Our team is multiple orders of magnitude smaller than the RabbitMQ community. Please help others help you by providing a way to reproduce the behavior you're
observing, or at least sharing as much relevant information as possible on the list:

• Server, client library and plugin (if applicable) versions used
• Server logs
• A code example or terminal transcript that can be used to reproduce
• Full exception stack traces (not a single line message)
• rabbitmqctl status (and, if possible, rabbitmqctl environment output)
• Other relevant things about the environment and workload, e.g. a traffic capture

Feel free to edit out hostnames and other potentially sensitive information.

When/if we have enough details and evidence we'd be happy to file a new issue.

Thank you.

[michaelklishin]

We cannot suggest anything with the amount of information provided. Our team is aware of a certain degradation on Erlang 20 but you have provided no details or way to reproduce or any environment details.

Timeouts is not necessarily an indication of a “performance degradation”.

[michaelklishin]

Specifically 3.6.11 and 3.6.12 aggressively use subprocesses, which was addressed already.

Again, this is a complete speculation and without environment information, PerfTest flags, server logs and so on we cannot suggest anything. Please take this to rabbitmq-users.

[michaelklishin]

In general 1000 of 1 kB messages/second or 1500 concurrent connections is not a heavy load for any version or client library. Something environment-specific is causing the timeouts.

[michaelklishin]

rabbitmq-users thread.