ActiveMQ
  1. ActiveMQ
  2. AMQ-903

ActivemMQ slows down after a rather small number of messages

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.1
    • Fix Version/s: 5.3.0
    • Component/s: None
    • Labels:
      None

      Description

      I have activemq with a postgresql backend running as a standalone server, and a client application that produces persistent messages in 50 threads. Each time I run my app it pushes as many msg as it can for about 62.5 seconds after which it quits. Although initially it works fast, every time I run my app it produces less messages:

      enqueue speed 50 threads: msg/second: 334.18333333333334
      second time: msg/second: 194.15
      third time: msg/second: 123.0
      fourth time: msg/second: 58.61666666666667
      fifth time: msg/second: 19.433333333333334
      sixth time: msg/second: 33.81666666666667
      seventh time: msg/second: 11.783333333333333
      eigth time: msg/second: 24.733333333333334
      ninght time: msg/second: 10.883333333333333

      After I ran the above test there seem to be 50241 msg in that queue.

      activemq=> select count(1) from activemq_msgs ;
      count
      -------
      50241
      (1 row)

      activemq=> select count(1) from activemq_acks ;
      count
      -------
      0
      (1 row)

      Note that I don't have any message consumers active for this test.

      Here is the way the client app connects:

      <bean id="jmsResourceAdapter"
      class="org.apache.activemq.ra.ActiveMQResourceAdapter">
      <property name="serverUrl" value="tcp://localhost:61616?wireFormat.cacheEnabled=false&wireFormat.tightEncodingEnabled=false" />
      </bean>

        Activity

        Hide
        Daniel Aioanei added a comment -

        Every time I ran my test app, the CPU usage staid on 100% so an artificial sleep-like delay doesn't seem to be involved.

        Show
        Daniel Aioanei added a comment - Every time I ran my test app, the CPU usage staid on 100% so an artificial sleep-like delay doesn't seem to be involved.
        Hide
        Daniel Aioanei added a comment -

        Just found out that while using the default DerbyDB db, the behaviour doesn't happen. Here are some numbers I got at consecutive tests with such a configuration:

        ActiveMQ/DerbyDb
        msg/second: 258.3833333333333
        msg/second: 293.15
        msg/second: 296.78333333333336
        msg/second: 273.0833333333333
        msg/second: 275.1333333333333

        with the same test application.

        Show
        Daniel Aioanei added a comment - Just found out that while using the default DerbyDB db, the behaviour doesn't happen. Here are some numbers I got at consecutive tests with such a configuration: ActiveMQ/DerbyDb msg/second: 258.3833333333333 msg/second: 293.15 msg/second: 296.78333333333336 msg/second: 273.0833333333333 msg/second: 275.1333333333333 with the same test application.
        Hide
        Daniel Aioanei added a comment -

        It seems that by specifying jms.useAsyncSend=true in the connection url, the throughput stays more or less constant even with a postgresql backend, and a single producer thread is enough to get the maximum performance.

        Show
        Daniel Aioanei added a comment - It seems that by specifying jms.useAsyncSend=true in the connection url, the throughput stays more or less constant even with a postgresql backend, and a single producer thread is enough to get the maximum performance.
        Hide
        Rob Davies added a comment -

        Looks resolved in current release

        Show
        Rob Davies added a comment - Looks resolved in current release

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel Aioanei
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development