Open Stack

On Dec 20, 2013, at 8:48 AM, Julien Danjou <julien at danjou.info> wrote:

> On Thu, Dec 19 2013, Herndon, John Luke wrote:
> 
> Hi John,
> 
>> The Rackspace-HP team has been putting a lot of effort into performance
>> testing event collection in the ceilometer storage drivers[0]. Based on
>> some results of this testing, we would like to support batch consumption
>> of notifications, as it will greatly improve insertion performance. Batch
>> consumption in this case means waiting for a certain number of
>> notifications to arrive before sending to the storage
>> driver. 
> 
> I think that is overall a good idea. And in my mind it could also a
> bigger consequences that you would think. When we will start using
> notifications instead of RPC calls for sending the samples, we may be
> able to leverage that too.
Cool, glad to hear it!

> Anyway, my main concern here is that I am not very enthusiast about
> using the executor to do that. I wonder if there is not a way to ask the
> broker to get as many as message as it has up to a limit?
> 
> You would have 100 messages waiting in the notifications.info queue, and
> you would be able to tell to oslo.messaging that you want to read up to
> 10 messages at a time. If the underlying protocol (e.g. AMQP) can
> support that too, it would be more efficient too.

Yeah, I like this idea. As far as I can tell, AMQP doesn’t support grabbing more than a single message at a time, but we could definitely have the broker store up the batch before sending it along. Other protocols may support bulk consumption. My one concern with this approach is error handling. Currently the executors treat each notification individually. So let’s say the broker hands 100 messages at a time. When client is done processing the messages, the broker needs to know if message 25 had an error or not. We would somehow need to communicate back to the broker which messages failed. I think this may take some refactoring of executors/dispatchers. What do you think?

> 
> -- 
> Julien Danjou
> /* Free Software hacker * independent consultant
>   http://julien.danjou.info */

-----------------
John Herndon
HP Cloud
john.herndon at hp.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4958 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/1e695b25/attachment.bin>