[rabbitmq-discuss] Expected msg/s per CPU core

[Tim Watson]

Hi

On 19 May 2013, at 08:55, Nikola Savic wrote:

> With every execution, PHP scripts connects to RabbitMQ and post 1-3 messages. Since we're tracking banner displaying, additionally when displayed to user, each page generates 3-5 more messages. 
> 
> So, on producer side, we have many connections being made and 1-3 short messages sent on single queue.
> 
> On consumer side we have worker PHP processes, which are connected once and receive messages.

I know next to nothing about PHP and its rabbit bindings, but in general, I suspect that the performance is poor because, instead of maintaining a persistent connection in your application, you're trying to reconnect every time you wish to interact with the broker.

> From time to time, we're sending ECHO (loopback messages) from producers to themselves, because we noticed that producers do not recognize RabbitMQ server has gone away or that VIP has switched to different server. With each ECHO message new connection is established.
> 

That is what AMQP heartbeats are for, when you're using a persistent connection. Presumably there is some way to maintain a connection (or pool of connections) in your PHP application and reuse them, rather than creating a new connections each time you want to send or receive messages. It is channels that are lightweight and can be created and thrown away cheaply, for short winded interactions like yours. Connections however, cost more to set up and tear down. I'm surprised this isn't familiar territory, since the same principles (i.e., the need to pool/cache connections) is common to all remote services, including more obvious ones like relational databases.

Tim