[rabbitmq-discuss] Poor performance using a single RabbitMQ connection on high-latency networks
holger.hoffstaette at googlemail.com
Sat Feb 6 03:32:35 GMT 2010
On Fri, 05 Feb 2010 16:59:50 +0000, Matthew Sackman wrote:
> I've just done some testing and found that removing our settings and
> relying on the OS to set them does not, in any case I can come up with,
> improve performance. I'm curious - you've said that you always set them to
> 65536, and there certainly seems to be evidence that that helps over
I just tend to remove them and use the host defaults out of
habit; this gave the best results in the one case where I needed to have
an eye on production performance. That was over a year ago though.
The part that I found curious was why fixing the server values worked
for Vladimir, whereas changing the client did apparently not - even though
that's where the connection originated. This could have been caused by a
peculiar behaviour of the broker, erlang or something else. Don't know
> But what about with no explicit setting of sndbuf and recbuf over WANs. Is
> the performance the same as manually setting to 65536, or the same as our
> explicit defaults, or something else?
Err..I wasn't the original poster of this thread and don't even have
Rabbit running over a WAN. I guess that's for Vladimir to answer.
FWIW the max initial window size without window scaling is 65535 (16 bit)
so anything larger may or may not work out correctly, especially through
routers or firewalls. If you really want to know what a client and server
agree on you'll need to fire up Wireshark and look at the first SYN/ACK
sequence on connection establishment. This may (hopefully will) then be
scaled up dynamically as data starts to flow.
See e.g.: http://support.novell.com/techcenter/articles/ana20021203.html
(ignore the Netware bits ;)
This rabbit hole goes deep..
More information about the rabbitmq-discuss