[rabbitmq-discuss] RabbitMQ with Socket Server
Alex Gentle
alexgentle at sify.com
Tue Sep 22 03:28:20 BST 2009
Hi Chuck,
>I think we are getting ahead of ourselves. Your original post indicated
that your code did not work but now you are worried about performance. Let's
get your code working first and then you can worry >about optimizing it
later.
>Can you successfully publish your messages yet? If so, can you pop them off
of the queue to read them?
Yes. The code is working. I can publish and retrieve the messages from the
queue. It works well.
>Polling is usually a bad idea particularly since it requires a lot of
unnecessary messaging. Most AMQP libraries I have seen allow for two ways to
fetch messages. One way is to "get" them from the >queue which is a
synchronous operation. The second way is to "subscribe" to a queue and have
it asynchronously push messages to the subscriber. You want to investigate
this second methodology >for your application. Async operations result in
slightly more complex code but they will let you scale better than
polling/synchronous operations.
This is news to me. I thought that client has to run the call to fetch the
message that is in the client's queue, even if the client subscribes to it.
Could you please explain pushing messages to the subscriber. If I have
socket server in the middle, will it block the pushed messages? I want to
trigger some kind of signal from rabbitmq to the client when a message is
waiting for the client so that client doesn't need to poll every few
seconds.
Thank you.
On Fri, Sep 18, 2009 at 5:27 AM, Chuck Remes <cremes.devlist at mac.com> wrote:
>
> On Sep 17, 2009, at 7:40 PM, Alex Gentle wrote:
>
> >Once you have parsed the message from socket server and determined it >should go to rabbit, you publish the message to it.
>
>
>
> I don’t know Ruby. I wrote a PHP program that parse the message from socket server and pass the message to RabbitMQ server.
>
>
>
> I wrote the examples in ruby since the code is very compact. You can
> perform the same operations in any language that has an AMQP library.
>
>
> The catch here is the performance. iPhone needs to query for the message in the queue every few seconds.
>
>
>
> I think we are getting ahead of ourselves. Your original post indicated
> that your code did not work but now you are worried about performance. Let's
> get your code working first and then you can worry about optimizing it
> later.
>
> Can you successfully publish your messages yet? If so, can you pop them off
> of the queue to read them?
>
>
> Let us assume
>
> that User A and User B chats thru iPhone application. User A sends the message to RabbitMQ.
>
>
>
> User A -> Socket Server -> RabbitMQ Server
>
>
>
> RabbitMQ has no way of sending the notification to User B that some message is waiting for him.
>
>
>
> User B needs to check the RabbitMQ server every 5 seconds to see if there is any message in his queue.
>
>
>
> Imagine there are 10,000 users like user A and B. All of them will be sending the message thru socket server to RabbitMQ server. Socket
>
> server can handle all the traffic. It’s a piece of cake for RabbitMQ to handle the traffic. But, the poor PHP program in the middle
> (between socket server and RabbitMQ) can’t handle all the incoming and outgoing requests with ease. It’s going to slow down the process.
>
> Users will see substantial delay in sending and receiving messages.
>
>
>
> Is there a better way to do it? Thanks.
>
>
> Polling is usually a bad idea particularly since it requires a lot of
> unnecessary messaging. Most AMQP libraries I have seen allow for two ways to
> fetch messages. One way is to "get" them from the queue which is a
> synchronous operation. The second way is to "subscribe" to a queue and have
> it asynchronously push messages to the subscriber. You want to investigate
> this second methodology for your application. Async operations result in
> slightly more complex code but they will let you scale better than
> polling/synchronous operations.
>
> cr
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://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/20090921/4299d4c0/attachment.htm
More information about the rabbitmq-discuss
mailing list