[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