ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

magellings
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!

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

James Strachan-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 :)

Could you give us any idea what your test case is doing?
--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

magellings
Here is a our scenario (P= producer, C=consumer, BrKR = broker, t=topic, vt=virtual topic)

                     |         |
  P1 -- vt1 --> |         | -- t1 (durable), vt1 ----> C1 ---- t2 ----> BrKR 1
  P2 -- t1 -->  |         |
  P3 -- t1 -->  |BrKR 1| -- t1 (durable), t5 (durable) --> C2 -- t3 -->
  P4 -- t2 -->  |         |                                                              BrKR 2  --- t3 (durable), t4 ---> C4
  P5 -- t2 --> |          | --- t1, t2 ------> C3 --- t4 -------------->
  P6 -- t5 --> |          |
                    |         | ---- vt1, t5 (durable) ---> C5 -- t2 --> BrKR 1

    * First producer (P1) sends 10000 msgs to “VirtualTopic.t1”
    * Two producers (P2/P3) send 10000 msgs to t1.
    * Two producers (P4/P5) send 10000 msgs to t2.
    * One producer (P6) sends 10000 msgs to t5.

As the consumers then process the messages they also produce messages on various topics.

We are using JDBC persistence, but we also were using it with our testing of ActiveMQ 5.2.
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

magellings
Those 10000s should be 1000s.  Sorry :)
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

magellings
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
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

Timothy Bish-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

I believe this was documented in this issue:
https://issues.apache.org/activemq/browse/AMQNET-274

Regards

--
Tim Bish
------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: tabish121
Blog: http://timbish.blogspot.com/


Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

magellings
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....

Does that make sense?
Reply | Threaded
Open this post in threaded view
|

Re: ActiveMQ 5.4.1 slower than ActiveMQ 5.2???

fendi
This post has NOT been accepted by the mailing list yet.