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

Nikola Savic niks at osic.rs
Sun May 19 15:06:00 BST 2013


Thanks ... this looks like interesting solution ... not sure how our 
admins will like to have one more layer of technology that needs 
monitoring and HA settings :(

Would STOMP be better approach to connect to RabbitMQ from PHP?

On 05/19/2013 03:32 PM, Laing, Michael P. wrote:
> 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
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130519/5b1c6032/attachment.htm>


More information about the rabbitmq-discuss mailing list