ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

Hi.

We're testing out ActiveMQ 5.4.1 and it is much slower than ActiveMQ 5.2. In our test case, with v5.2 we were able to process about 520,000 messages in about 9 hrs but with ActiveMQ 5.4.1 it takes 18hrs to process 21,000 messages. So processing 520,000 messages would take days.

Are there any default configurations that may be different between these two versions causing the extra slowness? Any bugs fixed in between versions (e.g. producer flow control) that could be causing the poor performance?

If anyone has any ideas on why ActiveMQ 5.4.1 is slower than ActiveMQ 5.2 that would be great!

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

On 18 November 2010 15:06, magellings <[hidden email]> wrote:
> Hi.
>
> We're testing out ActiveMQ 5.4.1 and it is much slower than ActiveMQ 5.2.
> In our test case, with v5.2 we were able to process about 520,000 messages
> in about 9 hrs but with ActiveMQ 5.4.1 it takes 18hrs to process 21,000
> messages.

Thats very slow. Thats barely 1000 messages an hour; ActiveMQ
typically can typically do a 1000 or so a *second* when running on a
reasonably new laptop, so its about 3000X too slow :)

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

Found the culprit!!! Failover transport options for the NMS provider changed to require a "transport" prefix. This appears to have been a breaking change from an early version of the provider.

This:

?AsyncConnect=true

now has to be this:

?transport.AsyncConnect=true

Otherwise, with .NET, if the first host is the slave it takes about 20s before the socket connection attempt times out and it moves on to the next host in the list. AsyncConnect tries to connect to all the hosts at once.

Speaking of breaking changes, how are they communicated to developers? This change also affected reconnect behavior. So for example, the *Reconnect* options now require the transport prefix too.

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

On Thu, 2010-11-18 at 13:12 -0800, magellings wrote:

> Found the culprit!!! Failover transport options for the NMS provider changed
> to require a "transport" prefix. This appears to have been a breaking
> change from an early version of the provider.
>
> This:
>
> ?AsyncConnect=true
>
> now has to be this:
>
> ?transport.AsyncConnect=true
>
> Otherwise, with .NET, if the first host is the slave it takes about 20s
> before the socket connection attempt times out and it moves on to the next
> host in the list. AsyncConnect tries to connect to all the hosts at once.
>
> Speaking of breaking changes, how are they communicated to developers? This
> change also affected reconnect behavior. So for example, the *Reconnect*
> options now require the transport prefix too.
>
> &transport.MaxReconnectAttempts=6&transport.ReconnectDelay=20&transport.UseExponentialBackoff=false

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

Thanks Tim! :)

I was hoping there was a more generalized list of breaking changes. Something included with the specific version. Jumping through all the issues out there would be quite tedious, especially when moving from pre-v1.2 to v1.4. This is especially true if we are talking the broker instead of the NMS provider.

Breaking changes at design/compile time are much different then hidden breaking changes like these. If anything it probably would have been best to keep the previous failover options working and backwards compatible. I know there's a fine line there though....