<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>