<div dir="ltr">Interesting. We don't use persistent messages. In fact the proxy clusters, which stand between our internal clients and the core clusters, explicitly remove persistence in case our clients 'forget'. We rely on replication instead; our persistence requirements are 'outsourced' to a global Cassandra cluster. So no disk IO hence no IO wait - our primo defense against network partitions in AWS/EC2, and a nice performance boost.<div>
<br></div><div>Although principles play a part too: idempotency - when in doubt, reconnect/resend/resubscribe; tolerate replicas. And we try to realistically engineer for 5 9's of reliability or more, not 100%, as we can decompose that target into realistic actions/costs.<br>
<div><br></div><div>ml</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 12:21 PM, Jason McIntosh <span dir="ltr"><<a href="mailto:mcintoshj@gmail.com" target="_blank">mcintoshj@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On our systems, we've seen consistent 400/sec on some queues. During a heavy data load roughly 2500/sec per queue (these are short lived usually).  Usually at that point flow control kicks in as our consumers can't quite keep up.  We use x-consistent-hashes to get around network latency and shovel each queue in a hash.  SO publishers publish to a fanout queue with a random routing key, which is bound to an x-consistent-hash exchange bound to 8 queues.  Each of the 8 queues is shoveled independently with a 1500 prefetch.  We've not been able to overload this mechanism easily - the drive IO is typically our limiting factor.  Or the consumers as stated on the remote side.  And that's because we're doing persistent messages, publisher confirms, and a whole lot of checks to make sure we don't ever lose anything.<span class="HOEnZb"><font color="#888888"><div>

<br></div><div>Jason</div></font></span></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 10:22 AM, Laing, Michael <span dir="ltr"><<a href="mailto:michael.laing@nytimes.com" target="_blank">michael.laing@nytimes.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Our volumes are quite variable on the shovels, representing a high overall degree of variability in our message volumes.<div>

<br></div><div>Just looking over the last 24 hours, shovel volume ranged from 25/sec to 2,500/sec on our Oregon core cluster.</div>
<div><br></div><div>Best,</div><div><br></div><div>Michael</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 1:14 PM, Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com" target="_blank">0x6e6562@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael,<br>
<div><br>
On Fri, Feb 28, 2014 at 12:45 PM, Laing, Michael<br>
<<a href="mailto:michael.laing@nytimes.com" target="_blank">michael.laing@nytimes.com</a>> wrote:<br>
> So I turned to shovels for more simplicity and control at the expense of<br>
> more difficult configuration.<br>
<br>
</div>Yes, it is quite a low level tool, but I guess sometimes your<br>
requirements are intricate enough to need to reach down to the lower<br>
layer.<br>
<div><br>
> Some of our core clusters support the 'retail' layer of instances that<br>
> gateway to clients (candles?). We are introducing federation into one of<br>
> these communication links because we want the propagation of client bindings<br>
> from the gateway instance to the core - an excellent feature of federation<br>
> and an important refinement for us.<br>
<br>
</div>Using federation to implement an AMQP gateway seems like a common<br>
pattern. One wonders why it didn't go into the AMQP spec ....<br>
<div><br>
> Initially I had thought that the 'new' federation replaced the 'old' shovel,<br>
> but this is not true - each tool has its place although their capabilities<br>
> overlap.<br>
><br>
> With easier configuration in 3.3, the lowly shovel may get its due!<br>
<br>
</div>It's interesting to see that the shovel still lives on, despite it<br>
being quite an agricultural component. What sort of message volumes<br>
are you guys processing with this, BTW?<br>
<br>
Thanks for being so detailed about your experiences, it's much appreciated.<br>
<br>
Cheers,<br>
<br>
Ben<br>
<div><div>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <br><div dir="ltr">Jason McIntosh<br><a href="https://github.com/jasonmcintosh/" target="_blank">https://github.com/jasonmcintosh/</a><br>
<a href="tel:573-424-7612" value="+15734247612" target="_blank">573-424-7612</a></div>
</div></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>