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

[Michael Klishin]

Priyanki Vashi:

> content header = 88 bytes ( does not show any direct info so not sure)
> basic.publish frame = 85 bytes ( shows details of queue, exchange, routing key etc) 
> content body = 137 bytes ( in this my payload is 100 bytes of string + 37 bytes might be checksum etc.)
> basic.ack = 87 bytes (shows delivery tag number) 
> 
> so from this I interpreted as 297 bytes  non-payload + 100 bytes of actual payload = 397 total bytes for every message on wire. 
> 
> Is this not normal ? 

I'd need to sit down and calculate how many bytes would a bare content header be packed into
but it's about right, except that

 * content header and body will vary depending on what you publish, what values the properties have, etc
 * basic.ack is optional, that is, you can publish without acks (which trades safety for improved throughput)

I'm slightly surprised that basic.publish frame is almost 90 bytes but it may be the case if e.g.
exchange name is unusually long.

> My publisher and consumer code looks like this. 

I assume it wasn't pasted by accident?

> 2) Regarding Interrupts and context switches point:
> I agree and understand what you said about context switch but I wanted to bring this up since I felt my CPU was spending lot of time in doing context switches and that could be one of the reason that I don't get any higher throughput even if I increase number of producer and receiver. 

How many cores (logical) does your CPU have? Do you only run a publisher and RabbitMQ on this machine?

> 3) Regarding changing to faster clients like Java or amqpc:
> My current concern is not that I don't have sufficinet throughout, I would like to understand given the fact later project need to use python based client and not java based client, would like to understand how system resources are used by rabbitmq. 

Seeing what kind of throughput you get with MulticastMain and/or amqpc will show you
how fast your hardware, network and RabbitMQ node can go. This can prove if you
are limited by your publisher's performance.

Then you can profile your publisher to see what takes time. I wasn't suggesting that you
should just use Java for your project, only to see if you can get a noticeably better
throughput with a different client.
--
MK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130816/f1d5315a/attachment.pgp>