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

Sun May 19 14:32:14 BST 2013

You could try statelessd, which is designed for this scenario: https://github.com/gmr/statelessd

"The goal is to allow for persistent connections to RabbitMQ for systems and languages that do not facilitate long-running persisted connections like PHP."

Or use FastCGI  for your PHP.

ml

From: Michael Klishin <michael.s.klishin at gmail.com<mailto:michael.s.klishin at gmail.com>>
Reply-To: rabbitmq <rabbitmq-discuss at lists.rabbitmq.com<mailto:rabbitmq-discuss at lists.rabbitmq.com>>
Date: Sunday, May 19, 2013 7:40 AM
To: rabbitmq <rabbitmq-discuss at lists.rabbitmq.com<mailto:rabbitmq-discuss at lists.rabbitmq.com>>
Subject: Re: [rabbitmq-discuss] Expected msg/s per CPU core

2013/5/19 Nikola Savic <niks at osic.rs<mailto:niks at osic.rs>>
With every execution, PHP scripts connects to RabbitMQ and post 1-3 messages

So the consumer apps are constantly being terminated, started, then they connect and consume
messages (I assume using basic.get)? That's far from being very efficient, RabbitMQ was
really built with long-running apps in mind.

Plus, with basic.get and immediate processing you get one message at a time. With "push API"
consumers it can be multiple messages at once. See http://www.rabbitmq.com/tutorials/tutorial-two-python.html,
for example.

I don't really know what to recommend besides at least not reconnecting all the time. AFAIK php clients
only support basic.get and not "push" deliveries, neither a long-running PHP process can offer any
way of concurrent processing.

You can try fetching multiple messages before you process them.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130519/ab462b31/attachment.htm>