<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [rabbitmq-discuss] High cpu usage for Java RabbitMQ client? (solved, my fault)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Matthias,<BR>
<BR>
> The instructions do indeed need fixing. We are aware of that, but just<BR>
> haven't found the time to do it yet.<BR>
<BR>
There's never enough time for documentation :)<BR>
<BR>
> > Also, I have looked through the AMQP lists a little bit and saw some<BR>
> > discussion of a compressed or binary wire format, specifically<BR>
> > relating to market quotes. It looks like this is slated for 1.0, but<BR>
> > that would be ideal for me (since AMQP overhead is ~30-50% of my<BR>
> > message size now). Is there a roadmap to adoption?<BR>
><BR>
> You are the first person to ask about this :) We have thought about more<BR>
> compact encodings for messaging than present in AMQP. See, for example<BR>
> Tony's "Streamlining HTTP" post<BR>
> (<A HREF="http://www.lshift.net/blog/2009/02/27/streamlining-http">http://www.lshift.net/blog/2009/02/27/streamlining-http</A>), but we have<BR>
> no concrete plans for implementation yet.<BR>
<BR>
Have you thought about approaching the AMQP spec with Thrift or ProtocolBuffers encoding? Tony's post is very much inline with what I've found, we have a few messages that are very small (24 bytes) and some that are larger (~500 bytes) so the AMQP overhead is very noticeable. Disabling positive-ack from the queues helped alleviate some of the traffic, but not enough to matter.<BR>
<BR>
> Does the overhead really cause problems in your setup? Do you end up<BR>
> saturating the network?<BR>
<BR>
Well, our current system has about 50 clients each consuming a 3Mbps stream. I was hoping to be able to swap out the backend to AMQP and then perform optimizations using the routing keys. However, the AMQP "stream" would at that point bump to 5-6Mbps. That's not too practical over our WAN links. This just adds a little bit of effort to switch to AMQP, by reworking the client to query the more static data from a DB instead of streaming it over and over (so the discussions I've seen about last quote caching would be a nice feature). The eventual goal is to have clustered brokers that do the traffic management between the remote nodes that generate messages, so that the data that needs to be routed across our WAN links is, but the majority of the data will stay local to the producers for archiving.<BR>
<BR>
Thanks,<BR>
Rob<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>