[openstack-dev] [nova][oslo] RPC Asynchronous Communication

Zhi Yan Liu lzy.dev at gmail.com
Thu May 7 10:36:53 UTC 2015


I'd really like this idea,  async call will definitely improve overall
performance for cloud control system. In nova (and other components)
there are some slow tasks which handle resource with long time
running, which makes new tasks get a huge delay before getting served,
especially for the high concurrent request (e.g. provisioning hundreds
VMs) with high delay operation for the resource handling case.

To really archive the result of improving system overall performance,
I think the biggest challenge is it must makes all operations cross
components to be asynchronous in the handling pipeline, a synchronous
operation in the call path will makes the workflow still be
synchronous, the system still need to wait this synchronous operation
to be finish and it will makes delay/waiting keep there, and this kind
of synchronous operation are very familiar around the resource
handling case for now.

thanks,
zhiyan

On Thu, May 7, 2015 at 6:05 PM, ozamiatin <ozamiatin at mirantis.com> wrote:
> Hi,
>
> I generally like the idea of "async CALL". Is there a place in Nova (or
> other services) where the new CALL may be applied to see advantage?
>
> Thanks,
> Oleksii Zamiatin
>
> 07.05.15 12:34, Sahid Orentino Ferdjaoui пишет:
>
>> Hi,
>>
>> The primary point of this expected discussion around asynchronous
>> communication is to optimize performance by reducing latency.
>>
>> For instance the design used in Nova and probably other projects let
>> able to operate ascynchronous operations from two way.
>>
>> 1. When communicate between inter-services
>> 2. When communicate to the database
>>
>> 1 and 2 are close since they use the same API but I prefer to keep a
>> difference here since the high level layer is not the same.
>>
>>  From Oslo Messaging point of view we currently have two methods to
>> invoke an RPC:
>>
>>    Cast and Call: The first one is not bloking and will invoke a RPC
>>      without to wait any response while the second will block the
>>      process and wait for the response.
>>
>> The aim is to add new method which will return without to block the
>> process an object let's call it "Future" which will provide some basic
>> methods to wait and get a response at any time.
>>
>> The benefice from Nova will comes on a higher level:
>>
>> 1. When communicate between services it will be not necessary to block
>>     the process and use this free time to execute some other
>>     computations.
>>
>>        future = rpcapi.invoke_long_process()
>>           ... do something else here ...
>>        result = future.get_response()
>>
>> 2. We can use the benefice of all of the work previously done with the
>>     Conductor and so by updating the framework Objects and Indirection
>>     Api we should take advantage of async operations to the database.
>>
>>         MyObject = MyClassObject.get_async()
>>           ... do something else here ...
>>         MyObject.wait()
>>
>>         MyObject.foo = "bar"
>>         MyObject.save_async()
>>           ... do something else here ...
>>         MyObject.wait()
>>
>> All of this is to illustrate and have to be discussed.
>>
>> I guess the first job needs to come from Oslo Messaging so the
>> question is to know the feeling here and then from Nova since it will
>> be the primary consumer of this feature.
>>
>> https://blueprints.launchpad.net/nova/+spec/asynchronous-communication
>>
>> Thanks,
>> s.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list