Re: [openstack-dev] [oslo.messaging]Optimize RPC performance by reusing callback queue

2017-06-08 Thread Ken Giusti
Hi, Keep in mind the rabbit driver creates a single reply queue per *transport* - that is per call to oslo.messaging's get_transport/get_rpc_transport/get_notification_transport. If you have multiple RPCClients sharing the same transport, then all clients issuing RPC calls over that transport

Re: [openstack-dev] [oslo.messaging]Optimize RPC performance by reusing callback queue

2017-06-08 Thread Mehdi Abaakouk
Hi, On Thu, Jun 08, 2017 at 10:29:16AM +0800, int32bit wrote: Hi, Currently, I find our RPC client always need create a new callback queue for every call requests to track the reply belongs, at least in Newton. That's pretty inefficient and lead to poor performance. I also find some RPC

Re: [openstack-dev] [oslo.messaging]Optimize RPC performance by reusing callback queue

2017-06-08 Thread lương hữu tuấn
Hi, First of all, the correlation_id is needed for tracking the response for callback queue per client. What you said is the inefficiency of callback queue per request. In any case, callback queue is needed. About oslo_messaging, you can see the correlation_id in the driver of amqp. Br,

[openstack-dev] [oslo.messaging]Optimize RPC performance by reusing callback queue

2017-06-07 Thread int32bit
Hi, Currently, I find our RPC client always need create a new callback queue for every call requests to track the reply belongs, at least in Newton. That's pretty inefficient and lead to poor performance. I also find some RPC implementations no need to create a new queue, they track the request