Announcement Announcement Module
No announcement yet.
Performance of placing messages on a JMS Queue (SwiftMQ)? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Performance of placing messages on a JMS Queue (SwiftMQ)?

    I'm encountering the following performance issues when placing messages on a JMS queue (SwiftMQ) & was wondering if any one had any ideas what the problem might be?

    (1) If I create a simple java program, with just a main method which loads some xml spring and then has a loop that puts 1 million messages on the jms queue - I get a throughput of about 4100 messages per second (when I add a consumer I get a throughput of about 3000 messages per second) The spring xml just sets up a jms producer to put messages on the queue.

    (2) When I put the SAME spring xml code from one above into my project spring xml, I only get a throughput of about 15 messages per second? In this project there is quartz's job and from within that the execute method, the messages are placed on the queue. I have the repeat interval of this job set to just 1 ms. There is also some database lookups & inserts done during the execution, but I checked and these aren't causing any major time bottleneck. I even checked the execution times of the "execute" method of the quartz job and it was fine and doesnt explain why the messages are only getting on the queue at 15 per second (the convertAndSend method in my code for placing the messages on the queue is asynchronous). It seems some underlying thread that finally puts the message on the queue is somehow getting affected by the particular spring xml configuration of my project.


  • #2
    So, you just send the messages in a loop at the first case and perform different activities that produce message send at the second? The problem is at the logic used at the second case - you just send the messages rarely.

    You can insert a logging at the main processing stages or write a simple logging aspect in order to find the bottleneck.


    • #3
      Hi, thanks for your reply.
      I have actually done timing of the code and though yes in the second case it does not call the convertAndSend method as fast as it does in case one (as it has to execute a lot more logic), there is still something up in that the messages should be getting on the queue alot faster than they are. The convertAndSend method is asynchronous and so returns before the messages are actually placed on the queue - its like whatever thread(s) that this method passes the messages to, is getting seriously delayed when trying to place messages on the queue in case 2. For example all the database operations are only taking in the range of 5-30 ms and the repeat interval of the quartz job is only 1 ms. I was guessing maybe some logic connected with quartz (or something like that) executing under the covers might be delaying the other thread?

      Thanks again,


      • #4
        I recommend you to profile the application and check system resources distribution then.


        • #5
          You should also use SwiftMQ's springsupport.jar which provides connection pooling.

          Look at the SwiftMQ web site under "Developers".