<div dir="ltr"><div>Hi there,   </div><div>  Since our production application tier uses php, publisher connections can't be long lived. A typical use case is that a publisher will establish a connection, publish a message and close the connection. Normally, we have about ~1000 connections open with one or two hundred messages in the queues and with a publish rate of ~800 msgs/sec. We faced a situation where consumers weren't consuming for approx 2 mins which caused the cluster to become slow (probably too many publishers and no consumers). BTW, I am working on fixing the consumer issue separately. I noticed the connections started to pile up from the application tier and at one point we had ~11,000 open connections with ~70,000 msgs in the queues. As a result, cluster wasn't in a usable condition.</div>

<div><br></div><div>   What bothers me most about this situation is the total number of connections. Total messages seem to be non significant compared to what Rabbit cluster can handle. I would like to improve this situation by creating a service layer on top of RabbitMQ cluster with long lived connections (probably a java service) to avoid creating a connection on the fly and tearing it down. I am willing to take the performance hit on each requests for . Does this sound reasonable? Is there a best practice for a situation like this?</div>

<div><br></div><div>Thanks,</div><div>Shri</div><div><br></div></div>