
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>Hi Nadya,</div><div><br></div><div>Yep, that’s right, the notifications stick around on the server until they are acknowledged so there is extra overhead involved. I only have experience with rabbitmq, so I can’t speak for other transports, but we have used this strategy internally for other purposes, and have reached > 10k messages/second on a single consumer using batch message consumption (i.e., consume N messages, process them, then ack all N at once). We’ve found that being able to acknowledge the entire batch of messages at a time leads to a huge performance increase. This is another motivating factor for moving towards batches. But to your point, making this configurable is the right way to go just in case other transports don’t react as well.</div><div><br></div><div>Thanks,</div><div>-john</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Nadya Privalova <<a href="mailto:nprivalova@mirantis.com">nprivalova@mirantis.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span> Fri, 20 Dec 2013 15:25:55 +0400<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [Ceilometer][Oslo] Consuming Notifications in Batches<br></div><div><br></div><meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><div dir="ltr"><div><div><div>Hi John,<br></div><br>As for me your ideas look very interesting. As I understood notification messages will be kept in MQ for some time (during batch-basket is being filled), right? I'm concerned about the additional load that will be on MQ (Rabbit). <br><br></div>Thanks,<br></div>Nadya<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 3:31 AM, Herndon, John Luke <span dir="ltr"><<a href="mailto:john.herndon@hp.com" target="_blank">john.herndon@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Folks,<br><br>

The Rackspace-HP team has been putting a lot of effort into performance<br>testing event collection in the ceilometer storage drivers[0]. Based on<br>some results of this testing, we would like to support batch consumption<br>

of notifications, as it will greatly improve insertion performance. Batch<br>

consumption in this case means waiting for a certain number of<br>

notifications to arrive before sending to the storage<br>

driver.<br><br>

I¹d like to get feedback from the community about this feature, and how we<br>

are planning to implement it. Here is what I’m currently thinking:<br><br>

1) This seems to fit well into oslo.messaging - batching may be a feature<br>

that other projects will find useful. After reviewing the changes that<br>

sileht has been working on in oslo.messaging, I think the right way to<br>

start off is to create a new executor that builds up a batch of<br>

notifications, and sends the batch to the dispatcher. We’d also add a<br>

timeout, so if a certain amount of time passes and the batch isn’t filled<br>

up, the notifications will be dispatched anyway. I’ve started a<br>

blueprint for this change and am filling in the details as I go along [1].<br><br>

2) In ceilometer, initialize the notification listener with the batch<br>

executor instead of the eventlet executor (this should probably be<br>

configurable)[2]. We can then send the entire batch of notifications to<br>the storage driver to be processed as events, while maintaining the<br>

current method for converting notifications into samples.<br><br>

3) Error handling becomes more difficult. The executor needs to know if<br>any of the notifications should be requeued. I think the right way to<br>

solve this is to return a list of notifications to requeue from the<br>

handler. Any better ideas?<br><br>

Is this the right approach to take? I¹m not an oslo.messaging expert, so<br>

if there is a proper way to implement this change, I¹m all ears!<br><br>

Thanks, happy holidays!<br>

-john<br><br>

0: <a href="https://etherpad.openstack.org/p/ceilometer-data-store-scale-testing" target="_blank">https://etherpad.openstack.org/p/ceilometer-data-store-scale-testing</a><br>

1:<br><a href="https://blueprints.launchpad.net/oslo.messaging/+spec/bulk-consume-messages" target="_blank">https://blueprints.launchpad.net/oslo.messaging/+spec/bulk-consume-messages</a><br>

2: <a href="https://blueprints.launchpad.net/ceilometer/+spec/use-bulk-notification" target="_blank">https://blueprints.launchpad.net/ceilometer/+spec/use-bulk-notification</a><br><br>_______________________________________________<br>

OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote></div><br></div>

_______________________________________________

OpenStack-dev mailing list

<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>

</span></body></html>