[rabbitmq-discuss] Direct vs Topic exchange - Question

[Simon MacMullen]

Thanks. I was able to get this to run.

However, with the code as it stands I think it's hard to measure 
performance of the broker. In order to see how fast the broker can go, 
you need to have the client pushing it as hard as it can - therefore the 
broker pretty much needs to enter flow control by definition.

I attempted to make this happen by setting the rate limit in the client 
to 100,000 msg/s. However, this caused the memory usage of the client to 
explode - due to the line 115 of publisher_wrk.erl:

     amqp_channel:cast(Channel, Publish, Msg).

Since this is pushing messages as fast as possible into the client 
channel process, you end up filling its mailbox as you can give it 
messages faster than it can send them out on the wire.

After only a few seconds of this the client process was so big that my 
machine started to swap badly, bits of RabbitMQ got swapped out, and 
performance became very poor.

Changing this cast to a call slows the client down a bit (but not much) 
but makes its memory use stable at high message rates. With this change 
in place, and a very high rate limit, I was able to get:

direct, 1 producer,   1 consumer:   ~25kHz
topic,  1 producer,   1 consumer:   ~14kHz
direct, 10 producers, 10 consumers: ~25kHz
         (but queues grew since consumers could not keep up)
topic,  10 producers, 10 consumers: ~16kHz

on my workstation. This is very roughly what I would expect - with tiny 
messages quite a lot of the cost of each message is routing, and topic 
routing *is* more complex.

So I'm afraid I don't really trust the results you got - how were you 
choosing a rate limit for the client? Too low and you're not driving the 
broker as hard as you can, and with that cast in place, too high and 
you'll start to eat all memory and eventually cause RabbitMQ to get 
swapped out.

Cheers, Simon

On 03/05/12 20:45, Konstantin Kalin wrote:
> Hello, Simon.
>
> Thank you for looking at this. Sorry for causing troubles. Please see
> inline.
>
> On May 3, 2012, at 3:12 AM, Simon MacMullen wrote:
>
>> On 02/05/12 17:09, Konstantin Kalin wrote:
>>
>> OK, that's just a typo I assume, I'll change it to:
>>
>> Connection = connections:get_connection(),
>>
> Yep. It was typo.
>
>>
>> So it looks like the connection server is not getting started?
>>
> Yes. Connection was not created.
> Actually I don't know why AMQP connections are not created if you start
> apps from command line using *-s*. It works fine when an app is started
> in Erlang shell using same "start" function.
>
> I created start_publisher.sh and start_consumer.sh scripts. The scripts
> don't start the application actually. But they put proper ERL_LIBS and
> search path. Publisher and Consumer apps cannot work in same Erlang VMs
> because each app tries to create own Connection pool.
>
> I have added comments for API methods in publisher.erl and consumer.erl.
> See attached file.
>
> Here are steps that I use to start the test:
> _Consumer_:
> 1) start_consumer.sh
> 2) consumer:start(["amqp://guest:guest@10.10.161.237:5672"]).
> 3) consumer:start_consumer(<<"topic">>, <<"topic">>).
> _Publisher_:
> 1) start_publisher.sh
> 2) publisher:start(["amqp://guest:guest@10.10.161.237:5672"]).
> 3) publisher:start_publish(<<"topic">>, <<"topic">>, 1000, 1000).
>
> Hope it will work now :)
>
> I run several tests yesterday and got more confusing results:
> Topic Exchange
> 1) 1 Consumer and 1 publisher - RabbitMQ shows ~10k per second. (4 times
> less than same test with Direct)
> 2) 10 Consumers and 10 publishers - RabbitMQ shows ~4k per second. (10
> times less than same test with Direct).
> 3) 100 Consumers and 100 publishers - RabbitMQ shows same ~4k per
> second. (10 times less than same test with Direct).
>
> And I see "Flow control" on Publisher connections. CPU is ~300% and
> Memory is ~300kb (VM is 8 CPU and 4Gb). So VM machine is slightly loaded.
>
>>
>> Cheers, Simon
>>
>> --
>> Simon MacMullen
>> RabbitMQ, VMware
>
> Thank you,
> Kostya.
>
>
>


-- 
Simon MacMullen
RabbitMQ, VMware