[rabbitmq-discuss] Run RabbitMQ server with N scheduler threads

Simon MacMullen simon at rabbitmq.com
Mon Mar 19 14:27:35 GMT 2012


On 16/03/12 17:28, Katerina Roukounaki wrote:
> Since the RabbitMQ server is an Erlang application, I wanted to see
> whether it runs faster as I increase the number of scheduler threads in
> the Erlang VM that runs it (+S option of the erl program).
>
> For this purpose, I wrote a simple benchmark (in Erlang) that spawns P
> producer and P consumer processes and creates P queues. The i-th
> producer sends M messages to the i-th queue and the i-th consumer waits
> to receive them. My benchmark uses native Erlang messaging for sending
> and receiving messages.

So just to be clear: you are using the direct client? Or something else?

> I attach the results I get when I run the benchmark with P=M=1000 on a
> machine with 16 cores and assign 1, 2, …, 16 scheduler threads to the VM
> that runs the RabbitMQ server.
>
> As you can see, things get better up to 6 schedulers, but with 7 or more
> schedulers it seems that there is no further speedup.
> Do you have any idea why this is happening?

At a guess: hyperthreading? I assume your machine is 8 physical cores 
and 16 hyperthreads. In which case the extra cores presented by 
hyperthreading are presumably not helping much.

But I'm not an expert on the Erlang scheduler.

> Is there some kind of synchronization among the processes that the
> RabbitMQ server spawns that explains it or should I look for bugs in my
> benchmark?

All your producer-queue-consumer chains are independent, right? So it's:

P1 -> Q1 -> C1
P2 -> Q2 -> C2

?

If so then there's no synchronisation between the processes done by 
RabbitMQ.

You might want to play with the other scheduler options. +sbt looks 
particularly interesting...

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware


More information about the rabbitmq-discuss mailing list