Reply inline below:<div><br clear="all">Scott Mohekey<br>Systems/Application Specialist � Fleet � Telogis, Inc.<br><a href="http://www.telogis.com">www.telogis.com</a> �<a href="http://www.telogis.co.nz">www.telogis.co.nz</a> <br>
+1 949 625-4115 ext. 207 (USA) �+64 3339 2825 x207 (NZ)<br><br>Leading Global Platform for Location Based Services <br>--<br>This e-mail, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. �It is the property of Telogis. �If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, any attachments thereto, and use of the information contained, is strictly prohibited. �If you have received this e-mail in error, please notify the sender and permanently delete the original and any copy there of.<br>
<br><br><div class="gmail_quote">On Mon, Mar 22, 2010 at 11:58 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Mar 22, 2010 at 11:26:24AM +1300, Scott Mohekey wrote:<br>
> I'm trying to find out when the new persister will be available.<br>
<br>
</div>Me too!<br>
<div class="im"><br>
> I've seen<br>
> mention that it was to be ready by July of last year (<br>
> <a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-June/003667.html" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-June/003667.html</a>),<br>
> and further mention in November of it not being ready yet (<br>
> <a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-November/005386.html" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-November/005386.html</a><br>
> ).<br>
<br>
</div>Yes. Though the "new persister" was in very different states at both of<br>
occasions.<br>
<div class="im"><br>
> The reason I ask is that we are attempting to publish ~1000 msgs/sec on a<br>
> single rabbit node, in a persisted queue. The queue is then read by a java<br>
> app on a geographically distant server over the internet, using<br>
> basic.consume. We also require transactional consumption, so currently wrap<br>
> a batch of X (500 for example) messages in a transaction, acking the last<br>
> one (passing true to ack multiple). We have qos set to batch size * 2 (1000<br>
> in the above example).<br>
><br>
> We're only managing to get something like 50 or so msgs/sec at the moment.<br>
> The consumption of the messages is slow, but the tx.commit varies in speed<br>
> from a second to many (sometimes even as long as a minute).<br>
<br>
</div>Many things can affect this. Are the publishes coming from a single<br>
publisher client or from many clients? Are all the publishes going to<br>
the same queue or to several different queues? How big are the messages<br>
that you're publishing and which client library / language are you<br>
using?<br>
<div class="im"><br></div></blockquote><div><br></div><div>We have a single publisher, with 10 production queues which are duplicated for testing (so 20 queues all up). All of these queues are persistent.</div><div><br></div>
<div>We use a topic exchange, with messages being routed to one or more of the queues.</div><div><br></div><div>The publisher uses the .net client and does no transactions, while the consumer uses the java client and wraps batches of messages in transactions.</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> The version of rabbitmq we currently have installed is 1.7.0. We are<br>
> planning to test with 1.7.2 later today to see if this helps any.<br>
><br>
> What are we doing wrong?<br>
<br>
</div>The new persister is much better (at least an order of magnitude, and<br>
frequently several, depending on workload) at transactions. I would<br>
suggest you try compiling from source and using that. There are several<br>
people on this list who have been using the new persister with good<br>
success. There are occasionally bugs found, but we tend to fix them<br>
within hours.<br>
<br>
There haven't really been any new features added to the new persister<br>
for a few months - it has been solidifying nicely. However, the diff<br>
from the current default branch to the new persister branch (bug21673)<br>
shows the addition of 7000 lines of code. This is the reason why it is<br>
taking a long time to get through QA - not because it's buggy or faults<br>
are being found, but simply because it is a lot of very complex code.<br>
<br>
If you do choose to use the new persister, try to ensure the following:<br>
1) Try to make sure nothing else is writing to the disk that Rabbit is<br>
using - Rabbit is pretty good at managing the position of the disk head,<br>
but that tends to go wrong if other applications are writing at the same<br>
time.<br></blockquote><div><br></div><div>We have our instance of Rabbit running on a XenCenter vm, using shared fibre storage. Is this going to be a problem?</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2) Ensure plenty of free RAM so the OS can use it as disk cache. This<br>
means a lot of reads can be satisfied without going all the way to disk.<br></blockquote><div>We have given the vm 8 gigs at the moment.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3) You may wish to investigate different file systems - e.g. Matthias's<br>
desktop, Ubuntu, using ext4, gets a pitiful 9 transactions a second,<br>
where as my rather more carefully tuned debian sid system gets 500<br>
txns/sec on an ext3 disk, and 1100 on an ext4 SSD. See the thread at<br>
<a href="http://old.nabble.com/limit-number-of-messages-buffered-in-memory-in-new-persister-td27753311.html" target="_blank">http://old.nabble.com/limit-number-of-messages-buffered-in-memory-in-new-persister-td27753311.html</a></blockquote>
<div><br></div><div>We're using ext3.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
4) SSDs can go much faster for txns because their fsync cost is very<br>
very low.<br>
5) Publishing in parallel (several producers, all issuing txns<br>
individually) will get you even better performance.<font color="#888888"><br></font></blockquote><div><br></div><div>Will this make a difference even though we're not using transactions on the publishing side?</div><div>
<br></div><div>Also, it seems to me that the slow throughput is on the consumer side. Queues have no problem filling up with messages, faster than the consumers can keep up with them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">Matthew<br>
</font></blockquote></div><br></div>