I was thinking about using Messaging to do a little offline
"synchronized" messaging, the pattern being that a controller method
fires of a message and then blocks waiting for another message in
reply.
One big problem here seems to be the latency on the poller. I can fire
off 100 short messages to ActiveMq, but the poller chugs through these
messages at a top rate of about 3/sec (I'm doing nothing but printing
the message to console, obviously, to test this).
Other connectors have a polling_interval, but the Stomp adapter does
not and does not seem to respond to one.
Is this the adapter, ActiveMQ, overhead on ActiveMessaging, latency on
the poller? Is there any way to improve the throughput without kicking
up tons of pollers?
On Mon, May 19, 2008 at 6:36 PM, ara_vartanian <ara.vartan...@gmail.com> wrote:
> I was thinking about using Messaging to do a little offline > "synchronized" messaging, the pattern being that a controller method > fires of a message and then blocks waiting for another message in > reply.
cool - I do some stuff like this, it's what the receive method on the MessageSender module is for.
> One big problem here seems to be the latency on the poller. I can fire > off 100 short messages to ActiveMq, but the poller chugs through these > messages at a top rate of about 3/sec (I'm doing nothing but printing > the message to console, obviously, to test this).
> Other connectors have a polling_interval, but the Stomp adapter does > not and does not seem to respond to one.
> Is this the adapter, ActiveMQ, overhead on ActiveMessaging, latency on > the poller? Is there any way to improve the throughput without kicking > up tons of pollers?
That does seem slow to me; I'll run some tests.
Stomp does not poll per se; it has an open connection, and messages that match your subscriptions get pushed to this by the broker, so you aren't polling the broker - it knows what messages your connection should get, and pushes them down that open connection.
The only interval is how often you check to see if our connection has received io that is there in memory waiting, or of it is not, waiting for some to arrive - and there is no sleep in that loop in the activemessaging or stomp gem code, so there is nothing to tweak as far as an interval.
So that is different from amazon sqs for example, where there is no open connection or subscriptions, and each time you're receiving, you are making a new http request to the sqs service to see if there is anything in the queue.
I think there are some things you can tweak that might be faster - I think client ack mode might be slower, as the broker has to get your ack before it sends another message to the connection, whereas in auto mode it can have already pushed a new message to your connection while you are processing the previous message.
Are you running these tests with activemessaging in development mode, or with RAILS_ENV = production? ActiveMessaging is supposed to reload processors and the rails env between messages in dev mode (though I think this may have been broken by recent rails changes), so I would check out running not in dev mode to see any timing info.
Beyond that I think you get into activemq tuning.
And really, though you seem to want to resist this, the best way to speed this up is to have more pollers running, and specifically using processor groups so that you could have pollers equal to the number of mongrel instances that are dedicated to your synchronous processor so mongrel processes won't have to wait for one another.
> On Mon, May 19, 2008 at 6:36 PM, ara_vartanian <ara.vartan...@gmail.com>
> wrote:
> > I was thinking about using Messaging to do a little offline
> > "synchronized" messaging, the pattern being that a controller method
> > fires of a message and then blocks waiting for another message in
> > reply.
> cool - I do some stuff like this, it's what the receive method on the
> MessageSender module is for.
> > One big problem here seems to be the latency on the poller. I can fire
> > off 100 short messages to ActiveMq, but the poller chugs through these
> > messages at a top rate of about 3/sec (I'm doing nothing but printing
> > the message to console, obviously, to test this).
> > Other connectors have a polling_interval, but the Stomp adapter does
> > not and does not seem to respond to one.
> > Is this the adapter, ActiveMQ, overhead on ActiveMessaging, latency on
> > the poller? Is there any way to improve the throughput without kicking
> > up tons of pollers?
> That does seem slow to me; I'll run some tests.
> Stomp does not poll per se; it has an open connection, and messages that
> match your subscriptions get pushed to this by the broker, so you aren't
> polling the broker - it knows what messages your connection should get, and
> pushes them down that open connection.
> The only interval is how often you check to see if our connection has
> received io that is there in memory waiting, or of it is not, waiting for
> some to arrive - and there is no sleep in that loop in the activemessaging
> or stomp gem code, so there is nothing to tweak as far as an interval.
> So that is different from amazon sqs for example, where there is no open
> connection or subscriptions, and each time you're receiving, you are making
> a new http request to the sqs service to see if there is anything in the
> queue.
> I think there are some things you can tweak that might be faster - I think
> client ack mode might be slower, as the broker has to get your ack before it
> sends another message to the connection, whereas in auto mode it can have
> already pushed a new message to your connection while you are processing the
> previous message.
> Are you running these tests with activemessaging in development mode, or
> with RAILS_ENV = production?
> ActiveMessaging is supposed to reload processors and the rails env between
> messages in dev mode (though I think this may have been broken by recent
> rails changes), so I would check out running not in dev mode to see any
> timing info.
> Beyond that I think you get into activemq tuning.
> And really, though you seem to want to resist this, the best way to speed
> this up is to have more pollers running, and specifically using processor
> groups so that you could have pollers equal to the number of mongrel
> instances that are dedicated to your synchronous processor so mongrel
> processes won't have to wait for one another.
> On May 19, 4:24 pm, "Andrew Kuklewicz" <kooks...@gmail.com> wrote: > > On Mon, May 19, 2008 at 6:36 PM, ara_vartanian <ara.vartan...@gmail.com> > > wrote:
> > > I was thinking about using Messaging to do a little offline > > > "synchronized" messaging, the pattern being that a controller method > > > fires of a message and then blocks waiting for another message in > > > reply.
> > cool - I do some stuff like this, it's what the receive method on the > > MessageSender module is for.
> > > One big problem here seems to be the latency on the poller. I can fire > > > off 100 short messages to ActiveMq, but the poller chugs through these > > > messages at a top rate of about 3/sec (I'm doing nothing but printing > > > the message to console, obviously, to test this).
> > > Other connectors have a polling_interval, but the Stomp adapter does > > > not and does not seem to respond to one.
> > > Is this the adapter, ActiveMQ, overhead on ActiveMessaging, latency on > > > the poller? Is there any way to improve the throughput without kicking > > > up tons of pollers?
> > That does seem slow to me; I'll run some tests.
> > Stomp does not poll per se; it has an open connection, and messages that > > match your subscriptions get pushed to this by the broker, so you aren't > > polling the broker - it knows what messages your connection should get, > and > > pushes them down that open connection.
> > The only interval is how often you check to see if our connection has > > received io that is there in memory waiting, or of it is not, waiting for > > some to arrive - and there is no sleep in that loop in the > activemessaging > > or stomp gem code, so there is nothing to tweak as far as an interval.
> > So that is different from amazon sqs for example, where there is no open > > connection or subscriptions, and each time you're receiving, you are > making > > a new http request to the sqs service to see if there is anything in the > > queue.
> > I think there are some things you can tweak that might be faster - I > think > > client ack mode might be slower, as the broker has to get your ack before > it > > sends another message to the connection, whereas in auto mode it can have > > already pushed a new message to your connection while you are processing > the > > previous message.
> > Are you running these tests with activemessaging in development mode, or > > with RAILS_ENV = production? > > ActiveMessaging is supposed to reload processors and the rails env > between > > messages in dev mode (though I think this may have been broken by recent > > rails changes), so I would check out running not in dev mode to see any > > timing info.
> > Beyond that I think you get into activemq tuning.
> > And really, though you seem to want to resist this, the best way to speed > > this up is to have more pollers running, and specifically using processor > > groups so that you could have pollers equal to the number of mongrel > > instances that are dedicated to your synchronous processor so mongrel > > processes won't have to wait for one another.
> On Mon, May 19, 2008 at 10:10 PM, ara_vartanian <ara.vartan...@gmail.com>
> wrote:
> > Hate to ask a stupid question, but how on earth do I change the
> > environment from the poller script?
> Same way you set the env for rails - set RAILS_ENV=production.
> You just need to set that env variable before you start the poller.
> > I can't use the start_consumers task, since I'm on a Windows box as of
> > the moment.
> Not sure why the rake task wouldn't work (i.e. start_consumers) - it doesn't
> rely on the daemons gem, so actually, I would expect that to work better.
> > On May 19, 4:24 pm, "Andrew Kuklewicz" <kooks...@gmail.com> wrote:
> > > On Mon, May 19, 2008 at 6:36 PM, ara_vartanian <ara.vartan...@gmail.com>
> > > wrote:
> > > > I was thinking about using Messaging to do a little offline
> > > > "synchronized" messaging, the pattern being that a controller method
> > > > fires of a message and then blocks waiting for another message in
> > > > reply.
> > > cool - I do some stuff like this, it's what the receive method on the
> > > MessageSender module is for.
> > > > One big problem here seems to be the latency on the poller. I can fire
> > > > off 100 short messages to ActiveMq, but the poller chugs through these
> > > > messages at a top rate of about 3/sec (I'm doing nothing but printing
> > > > the message to console, obviously, to test this).
> > > > Other connectors have a polling_interval, but the Stomp adapter does
> > > > not and does not seem to respond to one.
> > > > Is this the adapter, ActiveMQ, overhead on ActiveMessaging, latency on
> > > > the poller? Is there any way to improve the throughput without kicking
> > > > up tons of pollers?
> > > That does seem slow to me; I'll run some tests.
> > > Stomp does not poll per se; it has an open connection, and messages that
> > > match your subscriptions get pushed to this by the broker, so you aren't
> > > polling the broker - it knows what messages your connection should get,
> > and
> > > pushes them down that open connection.
> > > The only interval is how often you check to see if our connection has
> > > received io that is there in memory waiting, or of it is not, waiting for
> > > some to arrive - and there is no sleep in that loop in the
> > activemessaging
> > > or stomp gem code, so there is nothing to tweak as far as an interval.
> > > So that is different from amazon sqs for example, where there is no open
> > > connection or subscriptions, and each time you're receiving, you are
> > making
> > > a new http request to the sqs service to see if there is anything in the
> > > queue.
> > > I think there are some things you can tweak that might be faster - I
> > think
> > > client ack mode might be slower, as the broker has to get your ack before
> > it
> > > sends another message to the connection, whereas in auto mode it can have
> > > already pushed a new message to your connection while you are processing
> > the
> > > previous message.
> > > Are you running these tests with activemessaging in development mode, or
> > > with RAILS_ENV = production?
> > > ActiveMessaging is supposed to reload processors and the rails env
> > between
> > > messages in dev mode (though I think this may have been broken by recent
> > > rails changes), so I would check out running not in dev mode to see any
> > > timing info.
> > > Beyond that I think you get into activemq tuning.
> > > And really, though you seem to want to resist this, the best way to speed
> > > this up is to have more pollers running, and specifically using processor
> > > groups so that you could have pollers equal to the number of mongrel
> > > instances that are dedicated to your synchronous processor so mongrel
> > > processes won't have to wait for one another.
