You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by jonm <jo...@workingtoday.org> on 2007/04/12 19:10:01 UTC

STOMP latency vs other protocols

I'm experimenting with the STOMP broker feature of activeMQ with PHP.  I've
written publishers and consumers using STOMP and everything works, but with
a latency that is a little too high for my needs. Not being a java person I
haven't setup tests using java clients to do comparative benchmarking
against the PHP implementation (which is of course a particular angle at
answering my question here, but I thought i'd ask the group before diving
into figuring that out and if anyone has had lower latency with STOMP via
PHP).

Basically, I've got the queue running on the same machine as 2 clients (one
publisher, one consumer). When I send 1 message to a queue via STOMP i add
an extra header called 'microtime' and just before sending the message I set
that microtime header to the current time with millisecond precision. 
ActiveMQ then adds it's own timestamp to the message (i assume on receipt).
The activeMQ timestamp is often about 20ms after my added header.   I know
that the PHP function that sends the STOMP frame takes less than 1ms (so
significant latency should not be introduced via that send call. I also know
that after the queue gets the message and after the MQ timestamp is added to
the headers by MQ, it takes less than 3ms to deliver it to the subscriber. 
Using persistence vs non-persistence and async send to subscribers vs sync
does not significantly affect the latency (speeds up by a few ms on
average).

So it seems like MQ is taking upwards of 20ms (on my hardware which is an
IBM x306 series server pentium 4 3GHz machine) to take a STOMP frame and
process it to the point of stamping the message with the timestamp header.
On my lowly Dell Precision workstation it takes about 35-40ms.

Anyone have better STOMP performance or is STOMP performance known to be
slow due to the nature of MQ's STOMP broker having to do the STOMP
translation?

Would writing a C extension for PHP that implements the OpenWire protocol
speed things up? (Not that I'm ready to do that, but maybe!)

thanks!
jon

-- 
View this message in context: http://www.nabble.com/STOMP-latency-vs-other-protocols-tf3566925s2354.html#a9963979
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: STOMP latency vs other protocols

Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi John,

I would suggest investigating enabling the TCP_NO_DELAY option on the
stomp sockets.  This will tell the TCP socket to avoid buffering data
(by default they make an effort to increase network throughput by
putting more data into fewer IP packets).  This should decrease your
observed latency.

On 4/12/07, jonm <jo...@workingtoday.org> wrote:
>
> I'm experimenting with the STOMP broker feature of activeMQ with PHP.  I've
> written publishers and consumers using STOMP and everything works, but with
> a latency that is a little too high for my needs. Not being a java person I
> haven't setup tests using java clients to do comparative benchmarking
> against the PHP implementation (which is of course a particular angle at
> answering my question here, but I thought i'd ask the group before diving
> into figuring that out and if anyone has had lower latency with STOMP via
> PHP).
>
> Basically, I've got the queue running on the same machine as 2 clients (one
> publisher, one consumer). When I send 1 message to a queue via STOMP i add
> an extra header called 'microtime' and just before sending the message I set
> that microtime header to the current time with millisecond precision.
> ActiveMQ then adds it's own timestamp to the message (i assume on receipt).
> The activeMQ timestamp is often about 20ms after my added header.   I know
> that the PHP function that sends the STOMP frame takes less than 1ms (so
> significant latency should not be introduced via that send call. I also know
> that after the queue gets the message and after the MQ timestamp is added to
> the headers by MQ, it takes less than 3ms to deliver it to the subscriber.
> Using persistence vs non-persistence and async send to subscribers vs sync
> does not significantly affect the latency (speeds up by a few ms on
> average).
>
> So it seems like MQ is taking upwards of 20ms (on my hardware which is an
> IBM x306 series server pentium 4 3GHz machine) to take a STOMP frame and
> process it to the point of stamping the message with the timestamp header.
> On my lowly Dell Precision workstation it takes about 35-40ms.
>
> Anyone have better STOMP performance or is STOMP performance known to be
> slow due to the nature of MQ's STOMP broker having to do the STOMP
> translation?
>
> Would writing a C extension for PHP that implements the OpenWire protocol
> speed things up? (Not that I'm ready to do that, but maybe!)
>
> thanks!
> jon
>
> --
> View this message in context: http://www.nabble.com/STOMP-latency-vs-other-protocols-tf3566925s2354.html#a9963979
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com