<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello, Simon.<div><br></div><div>Thank you for your help here. See inline. </div><div><br><div><div>On May 4, 2012, at 3:11 AM, Simon MacMullen wrote:</div><br><blockquote type="cite"><div> amqp_channel:cast(Channel, Publish, Msg).<br><br>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.<br><br></div></blockquote><div><br></div><div>Yes. I know about this and this is why I created rate control on Client side. I thought that amqp_channel:cast(Channel, Publish, Msg) is better way to create a load :) Well, I have changed it to amqp_channel:call. Thank you for the advice. </div><br><br><blockquote type="cite"><div>direct, 1 producer, 1 consumer: ~25kHz<br>topic, 1 producer, 1 consumer: ~14kHz<br>direct, 10 producers, 10 consumers: ~25kHz<br> (but queues grew since consumers could not keep up)<br>topic, 10 producers, 10 consumers: ~16kHz<br><br>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.<br><br></div></blockquote><div><br></div>Well. It looks much better than I have :) And this is why I have asked to guide me what I'm doing wrong. I believe that RabbitMQ is great product and this is why I spend time on different tests to gain better understanding how it works. Thus I will use RabbitMQ more effectively. </div><div> <br><blockquote type="cite"><div>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.<br><br></div></blockquote><div>Understood. Usually the load test results causes a lot of confusions and questions since people makes load-tests for particular cases. </div><div>Please don't treat me wrong. I don't blame RabbitMQ. I rather will blame me for these strange results. </div><div><br></div><div>Let me explain my test setup:</div><div>I have two physical servers: 16 AuthenticAMD CPU, 16 Gb memory each. I use one physical server to virtualize RabbitMQ using KVM. RabbitMQ has 8 CPU and 4Gb. And there are no other VMs running on this physical server. And I use second physical server to run Consumer/Publisher code that you tried. </div><div><br></div><div>I repeated the test with direct and topic exchanges after I modified the code as mentioted above. </div><div>10 consumers and publishers for each type of exchange. I started publishing using following commands:</div><div>Test 1 - publisher:start_publish(<<"kkalin_test1">>, <<"topic">>, 20000, 20000, 10, 0).</div><div>Test 2 - publisher:start_publish(<<"kkalin_test">>, <<"direct">>, 20000, 20000, 10, 0). </div><div><br></div><div>I got: ~4k for Topic and ~60k for Direct :) See attached screenshots. I don't understand why. And I think it's hard to blame that <u>publisher_wrk</u> works slow for Topic exchange. There is no dedicated logic in software code that can affect messages rate depending on Exchange type. Same code, same machines and results with big differences. :(</div><div><br></div><div>May be you can provide a few advices what I can check to understand where is a bottle neck? </div><div>According to vmstat and htop, RabbitMQ and Client servers were not loaded in case of Topic Exchange. Looks like that RabbitMQ and Publisher are waiting each other. </div><div><br></div><div>Thank you for patience,</div><div>Kostya. </div><div><br></div><div><img height="574" width="1008" apple-width="yes" apple-height="yes" id="327d0918-4eb1-4315-86ce-f05e59fdad39" src="cid:F3DC5B23-3BF9-4D1C-9156-B2D3659AC349@five9.com"></div><div><img height="569" width="1014" apple-width="yes" apple-height="yes" id="d2c4747f-9562-4d2c-9e0b-780ecfccecdf" src="cid:0D80006A-3E08-4FD1-BCB9-806C99A62B38@five9.com"></div></div><br></div><div><br></div><div><br></div></body></html>