[rabbitmq-discuss] Throughput observation with RabbitMQ-3.1.3 and Erlang R16B01 - Single Node and Cluster Node

Priyanki Vashi vashi.priyanki at gmail.com
Thu Aug 15 11:29:37 BST 2013


Hi ,

I agree that my single producer is producing at constant rate but if I
increase number of producers, upt to say 10, then I should be able to see
proper usage of bandwidth right ?

Best Regards,
Priyanki.




On Thu, Aug 15, 2013 at 12:06 PM, Michael Klishin <mklishin at gopivotal.com>wrote:

> Priyanki Vashi:
>
> > 1) I have a quite high bandwidth between my client (producer & receiver)
> and server. Its around 9.2 Gbps. I have confirmed this by running iperf
> utility. But the maximum bandwidth I can reach is only 160 mbps. (I have
> pika client and single rabbitmq DISK type)
>
> This means your client cannot publish faster.
>
> > 2) I then also took network traces using wireshark, and what I observed
> that the AMQP overhead was quite high then the actual payload. If I send
> 100 bytes of string then overhead is 300 bytes so for every message of 100
> bytes I end up sending 400 bytes on wire.
>
> That does not sound right. AMQP 0-9-1 is a binary protocol and for every
> published message
> without custom headers, you should get a few dozens of bytes + message
> payload.
>
> The rest is probably TCP and IP overhead. There is no way to use RabbitMQ
> over UDP.
>
> > Since I have publish confirm/ack enabled so I understand part of this
> but there is also content header and some overhead in content body as well.
> > Is this standard for most of the clients or its specific for
> pika-clients only ?
>
> For a basic.publish with payload, you will get 3 frames:
>
> [basic.publish method frame] [content headers] [content payload]
>
> If the message has no content, it becomes
>
> [basic.publish method frame] [content headers]
>
> with every correct client.
>
> > 3) I then also try to observer how my system resources are used. I am
> new to this but after some googling I learnt a linux command 'dstat
> -dmnsy'. This provides me disk usage, RAM usage, interrupts and context
> switches, network send/recev. What I observer that as I increase no of
> producer/receiver, compare to DISK and RAM usage, its interrupts and
> context switches, which increases rapidly.
> >
> > what does this really mean ?
>
> When you publish rapidly, RabbitMQ stores messages (and some metadata
> about them) in RAM and on disk. Context switches means that OS gives
> various processes (your publisher, RabbitMQ, other processes running) time
> to execute. Flat network traffic rate suggests your publisher cannot
> publish any faster.
>
> > 4) Also, after certain point the value under network send/receive field
> remains constant. Not sure what does this mean also ?
>
> See above.
>
> >
> > I am pasting here one of the observed sample from dstat.
> >
> >    mq10 at mqserver10:~$ sudo rabbitmqadmin list queues vhost name node
> messages message_stats.publish_details.rate
> >
> +-------+------+-----------------+----------+------------------------------------+
> > | vhost | name |      node       | messages |
> message_stats.publish_details.rate |
> >
> +-------+------+-----------------+----------+------------------------------------+
> > | /     | 1    | Moon at mqserver10 | 5        | 3380.4
>           |
> > | /     | 2    | Moon at mqserver10 | 3        | 3649.0
>           |
> > | /     | 3    | Moon at mqserver10 | 6        | 3402.4
>           |
> > | /     | 4    | Moon at mqserver10 | 2        | 3450.8
>           |
> > | /     | 5    | Moon at mqserver10 | 3        | 3444.8
>           |
> >
> +-------+------+-----------------+----------+------------------------------------+
> > mq10 at mqserver10:~$ dstat -dmnsy
> > -dsk/total- ------memory-usage----- -net/total- ----swap--- ---system--
> >  read  writ| used  buff  cach  free| recv  send| used  free| int   csw
> >  100k 8974B| 188M 25.7M  115M 9674M|   0     0 |   0     0 |  15k 9759
> >    0    16k| 189M 25.7M  115M 9673M|6363k 4615k|   0     0 |  22k 6590
> >    0     0 | 189M 25.7M  115M 9673M|6666k 4847k|   0     0 |  22k 7846
> >    0     0 | 189M 25.7M  115M 9673M|6293k 4500k|   0     0 |  21k 7518
> >    0     0 | 189M 25.7M  115M 9674M|7049k 5121k|   0     0 |  22k 5936
> >    0     0 | 188M 25.7M  115M 9674M|6947k 5081k|   0     0 |  23k 6309
> >    0     0 | 188M 25.7M  115M 9674M|6387k 4741k|   0     0 |  22k 7020
> >    0     0 | 188M 25.7M  115M 9674M|6482k 4739k|   0     0 |  22k 7094
> >    0     0 | 189M 25.7M  115M 9673M|5642k 3976k|   0     0 |  18k 7586
> >    0     0 | 189M 25.7M  115M 9673M|6246k 4487k|   0     0 |  21k 7497
> >    0     0 | 189M 25.7M  115M 9673M|6631k 4827k|   0     0 |  21k 5924
> >    0     0 | 189M 25.7M  115M 9673M|6615k 4722k|   0     0 |  21k 5448
> >    0     0 | 190M 25.7M  115M 9672M|5677k 4051k|   0     0 |  20k 5757
> >    0     0 | 190M 25.7M  115M 9672M|6007k 4284k|   0     0 |  20k 6581
> >    0     0 | 190M 25.7M  115M 9672M|6983k 5052k|   0     0 |  23k 5704
> >    0     0 | 190M 25.7M  115M 9672M|6318k 4539k|   0     0 |  22k 6208
> >    0     0 | 190M 25.7M  115M 9672M|6769k 4862k|   0     0 |  23k 5952
> >    0     0 | 189M 25.7M  115M 9673M|6334k 4586k|   0     0 |  22k 6518
> >    0     0 | 191M 25.7M  115M 9671M|7019k 5089k|   0     0 |  23k 5937 ^C
>
> This suggests your publisher publishes at a roughly constant rate.
> Which, given spare network capacity (per your own words) suggests
> that the publisher cannot go any faster.
>
> > Also, what is the good profiler to run for rabbitmq server ?
>
> http://www.erlang.org/doc/efficiency_guide/profiling.html
>
> I'd like to point you that it's not RabbitMQ that seem to need profiling
> but your
> client.
>
> Try MulticastMain that ships with the RabbitMQ Java client or amqpc [1]
> to see what kind of thoughput your RabbitMQ node can offer with really fast
> clients.
>
> 1. https://github.com/gocardless/amqpc
> --
> MK
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130815/cd31e619/attachment.htm>


More information about the rabbitmq-discuss mailing list