[openstack-dev] [oslo][messaging] Further improvements and refactoring
dbelova at mirantis.com
Tue Jun 10 11:47:21 UTC 2014
No problem with creating the specs, we just want to understand if the
community is OK with our suggestions in general :)
If so, I'll create the appropriate specs and we'll discuss them :)
On Tue, Jun 10, 2014 at 3:31 PM, Davanum Srinivas <davanum at gmail.com> wrote:
> Dina, Alexey,
> Do you mind filing some spec(s) please?
> On Tue, Jun 10, 2014 at 7:03 AM, Dina Belova <dbelova at mirantis.com> wrote:
> > Hello, stackers!
> > Oslo.messaging is future of how different OpenStack components
> > with each other, and really I’d love to start discussion about how we can
> > make this library even better then it’s now and how can we refactor it
> > more production-ready.
> > As we all remember, oslo.messaging was initially inspired to be created
> as a
> > logical continuation of nova.rpc - as a separated library, with lots of
> > transports supported, etc. That’s why oslo.messaging inherited not only
> > advantages of now did the nova.rpc work (and it were lots of them), but
> > some architectural decisions that currently sometimes lead to the
> > performance issues (we met some of them while Ceilometer performance
> >  during the Icehouse).
> > For instance, simple testing messaging server (with connection pool and
> > eventlet) can process 700 messages per second. The same functionality
> > implemented using plain kombu (without connection pool and eventlet)
> > is processing ten times more - 7000-8000 messages per second.
> > So we have the following suggestions about how we may make this process
> > better and quicker (and really I’d love to collect your feedback, folks):
> > 1) Currently we have main loop running in the Executor class, and I guess
> > it’ll be much better to move it to the Server class, as it’ll make
> > relationship between the classes easier and will leave Executor only one
> > task - process the message and that’s it (in blocking or eventlet mode).
> > Moreover, this will make further refactoring much easier.
> > 2) Some of the drivers implementations (such as impl_rabbit and
> > for instance) are full of useless separated classes that in reality
> might be
> > included to other ones. There are already some changes making the whole
> > structure easier , and after the 1st issue will be solved Dispatcher
> > Listener also will be able to be refactored.
> > 3) If we’ll separate RPC functionality and messaging functionality it’ll
> > make code base clean and easily reused.
> > 4) Connection pool can be refactored to implement more efficient
> > reusage.
> > Folks, are you ok with such a plan? Alexey Kornienko already started
> some of
> > this work , but really we want to be sure that we chose the correct
> > vector of development here.
> > Thanks!
> > 
> > 
> > Best regards,
> > Dina Belova
> > Software Engineer
> > Mirantis Inc.
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Davanum Srinivas :: http://davanum.wordpress.com
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev