# Making the reply queues non-durable

**URL:** <https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155>\
**Category:** googlegroup\
**Created:** [October 20, 2016, 6:26am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155 "2016-10-20T06:26:31Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 20, 2016, 6:26am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/1 "2016-10-20T06:26:31Z")

</div>

Hi,  
The durable nature of the queues created by nameko, specifically the reply  
queues, cause high IO on our rabbitmq server.  
We want to make SOME of the reply queues (for some services) non durable,  
to reduce IO.

How can this be accomplished?  
T.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 20, 2016, 12:51pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/2 "2016-10-20T12:51:52Z")

</div>

Anyway, I've been playing a little with the code, and ended up with the  
following monkey-patch:

from nameko import rpc

def \_setup(self):  
&nbsp;&nbsp;&nbsp;&nbsp;service\_uuid = rpc.uuid.uuid4() # TODO: give srv\_ctx a uuid?  
&nbsp;&nbsp;&nbsp;&nbsp;service\_name = self.container.service\_name

&nbsp;&nbsp;&nbsp;&nbsp;queue\_name = rpc.RPC\_REPLY\_QUEUE\_TEMPLATE.format(  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service\_name, service\_uuid)

&nbsp;&nbsp;&nbsp;&nbsp;self.routing\_key = str(service\_uuid)

&nbsp;&nbsp;&nbsp;&nbsp;exchange = rpc.get\_rpc\_exchange(self.container.config)

&nbsp;&nbsp;&nbsp;&nbsp;self.queue = rpc.Queue(  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;queue\_name,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exchange=exchange,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;routing\_key=self.routing\_key,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;auto\_delete=True,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exclusive=True,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;durable=False # \<-- the patch  
&nbsp;&nbsp;&nbsp;&nbsp;)

&nbsp;&nbsp;&nbsp;&nbsp;self.queue\_consumer.register\_provider(self)

rpc.ReplyListener.setup = \_setup

basically what I did is patch the setup() method of the ReplyListener  
class, adding "durable=False" to the queue declaration.

This works (I can see that the reply queues are not durable), but I'm  
wondering if anything can break because of this.

Note that this patch is only used on clients connecting to nameko using  
ClusterRpcProxy.

Any comment would be appreciated.

T.

> **···**
>
> On Thursday, October 20, 2016 at 9:26:31 AM UTC+3, tsachi...@gmail.com wrote:
> 
> > Hi,  
> > The durable nature of the queues created by nameko, specifically the reply  
> > queues, cause high IO on our rabbitmq server.  
> > We want to make SOME of the reply queues (for some services) non durable,  
> > to reduce IO.
> > 
> > How can this be accomplished?  
> > T.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 21, 2016, 1:19pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/3 "2016-10-21T13:19:11Z")

</div>

Any help?

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [October 21, 2016, 2:22pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/4 "2016-10-21T14:22:33Z")

</div>

The patch you've applied here will do what you want with minimal negative  
implications.

Having said that, I think it's preferable to use subclasses to do this kind  
of override. The following would achieve the same thing as your patch:

# app/dependencies.py  
from nameko.rpc import ReplyListener as NamekoReplyListener  
from nameko.rpc import RpcProxy as NamekoRpcProxy

# override to create a non-durable queue  
class ReplyListener(NamekoReplyListener):

&nbsp;&nbsp;&nbsp;&nbsp;def setup(self):

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service\_uuid = uuid.uuid4()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service\_name = self.container.service\_name

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;queue\_name = RPC\_REPLY\_QUEUE\_TEMPLATE.format(  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service\_name, service\_uuid)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.routing\_key = str(service\_uuid)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exchange = get\_rpc\_exchange(self.container.config)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.queue = Queue(  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;queue\_name,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exchange=exchange,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;routing\_key=self.routing\_key,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;auto\_delete=True,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exclusive=True,  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;durable=False # the override  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.queue\_consumer.register\_provider(self)

# override to use custom ReplyListener  
class RpcProxy(NamekoRpcProxy):  
&nbsp;&nbsp;&nbsp;&nbsp;rpc\_reply\_listener = ReplyListener()

#app/service.py

from app.dependencies import RpcProxy

class Service:  
&nbsp;&nbsp;&nbsp;&nbsp;name = "nondurable"

&nbsp;&nbsp;&nbsp;&nbsp;rpc\_proxy = RpcProxy() # your subclass  
&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;...

Although this is our preferred pattern we aren't great at making it easy to  
do. This situation would be much better if we exposed "durable"` or  
"queue\_params" as an attribute of the ReplyListener class. Then you could  
do simply:

# app/dependencies.py  
from nameko.rpc import ReplyListener as NamekoReplyListener  
from nameko.rpc import RpcProxy as NamekoRpcProxy

# override to specify a non-durable queue  
class ReplyListener(NamekoReplyListener):  
&nbsp;&nbsp;&nbsp;&nbsp;queue\_params = {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'durable': False  
&nbsp;&nbsp;&nbsp;&nbsp;}

# override to use custom ReplyListener  
class RpcProxy(NamekoRpcProxy):  
&nbsp;&nbsp;&nbsp;&nbsp;rpc\_reply\_listener = ReplyListener()

I have started to introduce this pattern as part of a recent PR (see  
[https://github.com/onefinestay/nameko/pull/337/files#diff-f6430d9814b008d760592d1baedbed66R379\](https://github.com/onefinestay/nameko/pull/337/files#diff-f6430d9814b008d760592d1baedbed66R379%5C))

> **···**
>
> On Friday, October 21, 2016 at 2:19:12 PM UTC+1, tsachi...@gmail.com wrote:
> 
> > Any help?

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 21, 2016, 3:10pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/5 "2016-10-21T15:10:23Z")

</div>

Many thanks.  
I'll give it a shot.

T.

---

<div class="post-metadata">

**Author:** ![Johan](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@Johan](https://discourse.nameko.io/u/Johan)\
**Post date:** [October 24, 2016, 9:13am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/6 "2016-10-24T09:13:32Z")

</div>

If we take this discussion one step further. Your problem is high I/O on  
the rabbitMQ server.

Durability in general I would consider something that you want. How much  
I/O is high? There might be a solution in the rabbitMQ side of things  
instead of disabling the durability. But I might be ignoring something  
obvious?

Kindest

> **···**
>
> Den fredag 21 oktober 2016 kl. 17:10:24 UTC+2 skrev tsachi...@gmail.com:
> 
> > Many thanks.  
> > I'll give it a shot.
> > 
> > T.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 10:01am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/7 "2016-10-24T10:01:22Z")

</div>

Hi.  
If we run vmstat on the rabbit machine, we see the "wa" values (cpu waiting for io) at around 60-70.  
Considering a message rate of circa 100 messages/sec, these are some very bad numbers.  
We have around 100+ clients connecting the main service every second, thus creating 100+ durable queues every second.  
Raise the number of clients to 1000, and we are in a bad situation.  
Making the queues non-durable reduce the io but at least 50% (tested on our qa env).

T.

---

<div class="post-metadata">

**Author:** ![Johan](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@Johan](https://discourse.nameko.io/u/Johan)\
**Post date:** [October 24, 2016, 11:40am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/8 "2016-10-24T11:40:32Z")

</div>

Without knowing anything regarding server specs or rabbitmq setup this  
sound awfully high to me, and a bit strange 🙂

Though this is some concern relates to a nameko implementation the problem  
lies elsewhere. Even with message persitance 1000msg/sec shouldnt pose any  
problem.

The following post might be interesting to give some sort of relative  
performance measurement:

[https://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/](https://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/)

> **···**
>
> Den måndag 24 oktober 2016 kl. 12:01:22 UTC+2 skrev tsachi...@gmail.com:
> 
> > Hi.  
> > If we run vmstat on the rabbit machine, we see the "wa" values (cpu  
> > waiting for io) at around 60-70.  
> > Considering a message rate of circa 100 messages/sec, these are some very  
> > bad numbers.  
> > We have around 100+ clients connecting the main service every second, thus  
> > creating 100+ durable queues every second.  
> > Raise the number of clients to 1000, and we are in a bad situation.  
> > Making the queues non-durable reduce the io but at least 50% (tested on  
> > our qa env).
> > 
> > T.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 11:53am UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/9 "2016-10-24T11:53:03Z")

</div>

Hi,  
I'm aware of the link about the measurements, but note that they were taken with one producer and one consumer on a single queue.  
The nameko framework creates a queue for every client for the reply, so 100 parallel clients will create 100 reply queues, all persistent. Since our clients connect every second, this creates and destroys 100 queues every second on the disc.  
This is a lot of io, as we saw in the server stats.  
Maybe we can tune the machine better, but even out of the box, there should be no reason for high io, unless creating/destroying hundreds of durable queues every second IS very io intensive.

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 24, 2016, 12:00pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/10 "2016-10-24T12:00:43Z")

</div>

Hi,

Are these the same clients that are re-connecting? I guess they're  
non-nameko? Such clients probably wants to keep a pool of proxyes, to  
re-use the reply queue. See other discussions on this list, and  
e.g. [GitHub - jessepollak/flask-nameko: A wrapper for using nameko services with Flask](https://github.com/clef/flask-nameko)

Best,  
David

> **···**
>
> On Monday, 24 October 2016 12:53:04 UTC+1, tsachi...@gmail.com wrote:
> 
> > Hi,  
> > I'm aware of the link about the measurements, but note that they were  
> > taken with one producer and one consumer on a single queue.  
> > The nameko framework creates a queue for every client for the reply, so  
> > 100 parallel clients will create 100 reply queues, all persistent. Since  
> > our clients connect every second, this creates and destroys 100 queues  
> > every second on the disc.  
> > This is a lot of io, as we saw in the server stats.  
> > Maybe we can tune the machine better, but even out of the box, there  
> > should be no reason for high io, unless creating/destroying hundreds of  
> > durable queues every second IS very io intensive.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 12:06pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/11 "2016-10-24T12:06:17Z")

</div>

These are the same clients, using the ClustetRpcProxy class.  
They connect, get a reply, abd disconnect.  
If there's a way keep the reply queues alive, it would be great.  
How can I accomplish that?

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [October 24, 2016, 12:37pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/12 "2016-10-24T12:37:37Z")

</div>

I don't think turning off durability will give you a huge performance  
boost. Most of the cost here is in connecting and creating queues.

As David suggests, you should try to pool the proxies to re-use connections  
and reply queues. There are two existing implementations that do something  
like this ([GitHub - jessepollak/flask-nameko: A wrapper for using nameko services with Flask](https://github.com/clef/flask-nameko) and  
[https://github.com/and3rson/django-nameko\](https://github.com/and3rson/django-nameko%5C)). Try one of these (or something  
like them) and you'll see a dramatic improvement.

> **···**
>
> On Monday, October 24, 2016 at 1:06:18 PM UTC+1, tsachi...@gmail.com wrote:
> 
> > These are the same clients, using the ClustetRpcProxy class.  
> > They connect, get a reply, abd disconnect.  
> > If there's a way keep the reply queues alive, it would be great.  
> > How can I accomplish that?

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 24, 2016, 12:53pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/13 "2016-10-24T12:53:45Z")

</div>

What kind of project(s) are these clients embedded in? There is some  
initial work in [https://github.com/onefinestay/nameko/pull/357\](https://github.com/onefinestay/nameko/pull/357%5C). Pr also  
includes a few references e.g. the flask one i linked above

D

> **···**
>
> On Monday, 24 October 2016 13:06:18 UTC+1, tsachi...@gmail.com wrote:
> 
> > These are the same clients, using the ClustetRpcProxy class.  
> > They connect, get a reply, abd disconnect.  
> > If there's a way keep the reply queues alive, it would be great.  
> > How can I accomplish that?

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 1:02pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/14 "2016-10-24T13:02:54Z")

</div>

Here's an overview of our setup:  
There are clients (not browsers) that need to pull data from rabbit. The clients, for design reasons, don't have access to rabbit server.  
So they send a signal to a central process along with their id.  
The central process uses ClusterRpcProxy to connect to to nameko service and fetch the data in behalf of the client.  
The central service then returns the data to the client.

That's a single cycle. This happens once a second for every client, with over 100 clients.

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 24, 2016, 1:05pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/15 "2016-10-24T13:05:17Z")

</div>

Ok. I guess the question becomes: how does the "central process" work? i  
guess that's not a nameko service? how do the clients communicate with the  
central process? (the aim is to figure out if/how the central process could  
re-use the same clusterrpcproxy)

> **···**
>
> On Monday, 24 October 2016 14:02:54 UTC+1, tsachi...@gmail.com wrote:
> 
> > Here's an overview of our setup:  
> > There are clients (not browsers) that need to pull data from rabbit. The  
> > clients, for design reasons, don't have access to rabbit server.  
> > So they send a signal to a central process along with their id.  
> > The central process uses ClusterRpcProxy to connect to to nameko service  
> > and fetch the data in behalf of the client.  
> > The central service then returns the data to the client.
> > 
> > That's a single cycle. This happens once a second for every client, with  
> > over 100 clients.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 1:11pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/16 "2016-10-24T13:11:33Z")

</div>

The central service is a simple webserver that receives signals as http requests.  
As you guessed, it's not a nameko service. It connects to a nameko service using a ClusterRpcProxy class.

I took a look at the nameko-django implementation, and we're actually using a very similar pool (it stores ClusterRpcProxy instances and re-uses them) but still io is high.  
Are instances of ClusterRpcProxy bound to a dingle reply queue?

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 24, 2016, 1:17pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/17 "2016-10-24T13:17:48Z")

</div>

would you consider making it a nameko service (using nameko http)? then  
you'd be able to use a regular rpc proxy and get the queue re-use for free?  
if not, are you using any web framework? you'd have to look at the  
approaches in the links above

d

> **···**
>
> On Monday, 24 October 2016 14:11:33 UTC+1, tsachi...@gmail.com wrote:
> 
> > The central service is a simple webserver that receives signals as http  
> > requests.  
> > As you guessed, it's not a nameko service. It connects to a nameko service  
> > using a ClusterRpcProxy class.
> > 
> > I took a look at the nameko-django implementation, and we're actually  
> > using a very similar pool (it stores ClusterRpcProxy instances and re-uses  
> > them) but still io is high.  
> > Are instances of ClusterRpcProxy bound to a dingle reply queue?

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [October 24, 2016, 1:26pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/18 "2016-10-24T13:26:52Z")

</div>

We don't want to do major changes to our webserver. It does other things as well, so we don't want to rewrite everything as nameko services.

As I said, we are using a pool for ClusterRpcProxy, similar to the nameko-django implementation, but io is still high.  
Are these instances bound to a single reply queue?  
If we re-use them, no new queues are created?

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [October 24, 2016, 1:41pm UTC](https://discourse.nameko.io/t/making-the-reply-queues-non-durable/155/19 "2016-10-24T13:41:59Z")

</div>

That's correct. The cluster proxy creates a reply queue when you enter the  
context manager, which is pretty bad from a performance point of view. some  
of the approaches linked include ideas for how to re-use, which should give  
you a pretty big perf win

d

> **···**
>
> On Monday, 24 October 2016 14:26:52 UTC+1, tsachi...@gmail.com wrote:
> 
> > We don't want to do major changes to our webserver. It does other things  
> > as well, so we don't want to rewrite everything as nameko services.
> > 
> > As I said, we are using a pool for ClusterRpcProxy, similar to the  
> > nameko-django implementation, but io is still high.  
> > Are these instances bound to a single reply queue?  
> > If we re-use them, no new queues are created?