[rabbitmq-discuss] RabbitMQ perfomance testing & troubles

[Dmitriy Samovskiy]

Hi Alexey,

Alexey Slynko wrote:
> 
> Hi,
> 
> we have done some stress tests of rabbitmq. Our main goal was the ~10K
> messages per second and maximum cpu & ram usage. Two servers with equal
> configuration listed below were used for this task.
> 
What is your projected number of clients (producers and consumers combined)? In your tests 
below, it looks to me like you had 200, 1000 and 2000 clients - are these your expected 
levels? Each client is a socket. I think you might get higher throughput by reducing the 
number of clients.


> There is a system state after rabbitmq startup:
> 
> top - 22:41:58 up 3 days,  5:10,  3 users,  load average: 0.00, 0.00, 0.00
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 31089 rabbitmq  15   0 2499m  15m 1620 S    0  0.4   0:00.29 beam.smp


> 
> So, let's try to start 100 producer's and
> 100 consumer's. Each producer generate 10 msgs/sec (t
> 1000 msgs/sec at all)
May I suggest increasing the number of messages per second as an alternative test (instead 
of increasing the number of clients)?

> 
> $ java -jar RabbitmqFastMessagingProducerTest.jar 100 > client.log
> 
> System snapshot:
> 
> top - 22:50:39 up 3 days,  5:19,  3 users,  load average: 0.51, 0.11, 0.04
> 
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 
> 31089 rabbitmq  15   0 2520m  33m 1620 S  281  0.8   0:45.94 beam.smp
> 
>> $ java -jar RabbitmqFastMessagingProducerTest.jar 500 > client.log
> 
>   top - 23:22:10 up 3 days,  5:51,  3 users,  load average: 4.91, 2.89,  
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 
> 31566 rabbitmq  15   0 3062m 572m 1620 S  412 14.2  12:14.58 beam.smp


It also looks like you restarted the broker before you ran the last top above (changed 
PID). Is there a way to capture its memory footprint right after restart? The difference 
in virt mem is 500M, which is 20% of what the first top shows.


I think one of your your biggest bottlenecks in this case is the number of sockets that 
you ask your OS to juggle at the same time (I may be wrong however). Things you might want 
to try:
1. reduce the number of clients
2. reduce the number of sockets each broker has to open by setting up a RabbitMQ cluster


- Dmitriy