"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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...