"ataylor" wrote : The first thing I notice is that you are setting the timetolive on send to 1000ms, this means that most of these messages could expire and never be consumed, set this to 0. |
Removing timetolive did the trick. Apparently, expiring messages was killing the GC. Now, the picture's as follows: | | -- Sender | Sent per sec: 11417 | Sent per sec: 13772 | Sent per sec: 11489 | Sent per sec: 10700 | Sent per sec: 11397 | Sent per sec: 12361 | Sent per sec: 12043 | Sent per sec: 7591 | Sent per sec: 6297 | Sent per sec: 1126 | Sent per sec: 921 | Sent per sec: 1024 | Sent per sec: 870 | ... | | Sent per sec: 803 | Sent per sec: 373 | Sent per sec: 716 | Sent per sec: 768 | Sent per sec: 307 | Sent per sec: 768 | Sent per sec: 665 | Sent per sec: 460 | Sent per sec: 460 | Sent per sec: 563 | | -- Receiver | Received per sec: 12205 | Received per sec: 10278 | Received per sec: 9535 | Received per sec: 9949 | Received per sec: 9254 | Received per sec: 9110 | Received per sec: 7416 | Received per sec: 5673 | Received per sec: 3976 | Received per sec: 450 | Received per sec: 400 | Received per sec: 400 | Received per sec: 400 | Received per sec: 407 | .... | | Received per sec: 400 | Received per sec: 200 | Received per sec: 400 | Received per sec: 400 | Received per sec: 200 | Received per sec: 400 | Received per sec: 200 | Received per sec: 400 | Received per sec: 185 | As soon as paging starts, the message s/r rate gets limited by the DB and falls down dramatically. "ataylor" wrote : | Also you are sending messages as quickly as possible which isn't a true representation of what would happen in a real live deployment. | Unfortunately, it is close to real life: our data soruces are capable of generating several K worth of 1K messages/s, so we need to understand the messaging system limits in order to be able to sustain the data flow. "ataylor" wrote : | You are basically saturating the server with messages. i.e. if the max size of Q1 is 2000 messages, as soon as the consumer falls this many behind the producer the messages are paged to the database, slowing everything down. Try experimenting with the destination paging parameters(see the users guide) and add a throttle to your sender. I am not sure why the consumer falls behind so quickly. True, the producer does not do much, but neither does the consumer, and yet it is about 30% slower than the producer which leads to the queue explosion. For comparison, the same test program run with SwiftMQ : | -- Sender | Sent per sec: 42514 | Sent per sec: 43396 | Sent per sec: 43816 | Sent per sec: 44270 | Sent per sec: 44444 | Sent per sec: 43650 | Sent per sec: 44212 | Sent per sec: 43810 | Sent per sec: 44092 | Sent per sec: 43420 | Sent per sec: 43831 | Sent per sec: 43370 | Sent per sec: 43816 | Sent per sec: 44198 | Sent per sec: 43982 | Sent per sec: 43242 | ... | Sent per sec: 44326 | Sent per sec: 43464 | Sent per sec: 43702 | | -- Receiver | Received per sec: 42808 | Received per sec: 43986 | Received per sec: 43652 | Received per sec: 44426 | Received per sec: 43966 | Received per sec: 43680 | Received per sec: 44176 | Received per sec: 43709 | Received per sec: 43986 | Received per sec: 43832 | Received per sec: 43364 | Received per sec: 43673 | Received per sec: 43816 | Received per sec: 44264 | Received per sec: 43826 | Received per sec: 43314 | .... | | Received per sec: 44077 | Received per sec: 43806 | Received per sec: 43496 | The consumer always manages to keep up with the producer. VJ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128904#4128904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128904 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
