You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by MattFaulkner <ma...@gmail.com> on 2017/07/31 09:42:06 UTC

Schedule Message Delivery Producer Performance

Hi,

I'm looking at using the scheduler for delaying a large number of messages.
However, when testing I notice there is a big performance difference between
having the AMQ_SCHEDULED_DELAY value and not.

I created a simple producer and sent 1 million messages. 

WITH delay time taken - 2429 seconds
WITHOUT delay time taken - 264 seconds

Is this expected behaviour or am I missing something here?

Version: 5.13.2

Thanks,





--
View this message in context: http://activemq.2283324.n4.nabble.com/Schedule-Message-Delivery-Producer-Performance-tp4729053.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Schedule Message Delivery Producer Performance

Posted by Timothy Bish <ta...@gmail.com>.
On 07/31/2017 05:42 AM, MattFaulkner wrote:
> Hi,
>
> I'm looking at using the scheduler for delaying a large number of messages.
> However, when testing I notice there is a big performance difference between
> having the AMQ_SCHEDULED_DELAY value and not.
>
> I created a simple producer and sent 1 million messages.
>
> WITH delay time taken - 2429 seconds
> WITHOUT delay time taken - 264 seconds
>
> Is this expected behaviour or am I missing something here?
>
> Version: 5.13.2
>
> Thanks,
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Schedule-Message-Delivery-Producer-Performance-tp4729053.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Not really sure what the measurement is based on given the lack of 
details but I am not surprised that the scheduled message sends take 
longer, the scheduler store is not a high performance message store and 
I would not treat it as such.  If you are blasting a million messages at 
the broker with scheduled delay values then I'd maybe suggest that you 
take a step back and reconsider some of the design choices that got you 
there.

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/