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

[Nikola Savic]

Hi,

My conclusion was similar about cost of making new connection over and 
over again. However, PHP works so that I can not reuse resources between 
two runs :(

Some extensions, like MySQL, has support for persistent connections in 
itself. I didn't notice AMQP extension has anything like that :( Will 
look into it more.

The same goes for AMQP heartbeats, which I didn't notice in 
documentation :( Hopefully there is "hidden" option for turning it on. 
It's probably something client requests?

Thanks!
Nikola

On 05/19/2013 12:39 PM, Tim Watson wrote:
> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>