[
https://issues.apache.org/jira/browse/APLO-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442464#comment-13442464
]
Hiram Chirino commented on APLO-244:
------------------------------------
Ok. So the configuration of ActiveMQ and Apollo is not really apples to apples.
For example, if you make the consumer slow (have him sleep 1 second between
messages received). Apollo should allow producers to continue to produce and
it will swap messages to disk without stopping the producers. The ActiveMQ
configuration on the other hand will be buffering all the messages in memory
until you run out of memory and at that point the producers rate should drop to
zero.
> Apollo does not give priority to outgoing messages under stress
> ---------------------------------------------------------------
>
> Key: APLO-244
> URL: https://issues.apache.org/jira/browse/APLO-244
> Project: ActiveMQ Apollo
> Issue Type: Improvement
> Reporter: Lionel Cons
> Attachments: activemq.xml, APLO-244-87.png, APLO-244-89.png,
> APLO-244.png, APLO-244.xml, sbs-20120822-143646.pdf, sbs-20120822-150021.pdf
>
>
> Using the stomp-benchmark scenario file attached to APLO-241, one can play
> with the number of producers and the overall message rate via the
> producer_sleep parameter.
> On good hardware, Apollo could handle 60k msg/sec coming from 30k concurrent
> clients. This is good!
> However, when the message rate is further increased, Apollo spends most of
> its time queuing the messages it cannot deliver (since I have
> slow_consumer_policy=queue) instead of delivering them. The end result being
> that the topic consumer gets no messages at all, making the situation even
> worse (bigger message store).
> For instance:
> c_c1 samples: [
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> ]
> p_p1 samples: [
> 275403,208512,241756,238954,241702,269398,362274,390104,437176,408510,459625,454061,447085,454244,419557,413095,235546,76322,40296,12285,2979
> ,1891,1408,1110,866,824,921,909,909,984,988,861,601,332,251,164,165,256,425,495,495,583,660,656,551,783,825,668,680,447,164,165,165,165,165,178,402,329,330,209
> ]
> e_p1 samples: [
> 0,0,0,4,30,0,0,0,0,0,30,1,0,0,3,1,10,15,0,0,3,1,10,12,3,3,2,2,1,21,2,2,1,0,2,10,11,3,2,3,3,10,15,0,2,2,4,2,20,1,2,6,1,2,18,1,2,3,2,3
> ]
> p_p2 samples: [
> 204727,164350,193413,196598,193711,217585,269030,278368,319091,296477,325126,323323,267829,118000,35694,24693,15922,7836,4554,3212,2669,1595,1150,1116,994,538,984,1364,1276,1209,1322,1066,992,771,714,496,495,469,535,620,514,581,568,496,273,359,370,281,186,124,4,0,0,0,0,21,124,123,124,124
> ]
> e_p2 samples: [
> 0,0,0,8,29,1,0,0,0,0,33,2,1,0,1,2,20,11,0,0,0,5,17,9,1,2,3,5,1,21,0,4,5,3,3,10,10,5,3,3,2,14,9,6,6,2,3,3,17,4,4,1,5,1,22,2,4,3,3,9
> ]
> p_p3 samples: [
> 182945,158541,179534,175291,179664,198728,245723,259168,274541,190171,63161,24280,11886,6765,5802,5324,4299,2962,2183,1743,1273,779,424,262,83,0,363,596,596,429,380,397,368,307,1069,992,837,661,503,333,239,174,102,99,14,174,198,123,124,199,104,99,141,198,198,184,79,0,0,0
> ]
> e_p3 samples: [
> 0,0,0,10,32,1,0,0,0,1,39,2,1,0,2,1,21,12,0,1,3,2,21,10,1,2,2,3,3,23,4,2,4,3,1,16,10,2,3,4,2,16,12,4,4,4,4,5,18,3,2,3,10,3,21,1,5,5,5,2
> ]
> p_p4 samples: [
> 195131,164391,192826,184336,187915,206291,212340,103434,19850,7087,4013,3124,2173,2444,2389,1522,1074,1237,1149,820,517,316,197,249,289,176,102,166,84,0,833,892,353,36,332,311,59,0,0,0,0,0,0,0,0,0,0,0,87,332,321,154,0,0,0,12,83,37,0,0
> ]
> e_p4 samples: [
> 0,0,0,3,38,2,0,0,0,0,34,1,0,0,4,2,15,20,0,0,0,3,11,19,3,3,5,4,3,23,0,2,2,3,4,12,14,5,5,3,4,9,13,4,2,4,3,6,24,5,5,2,2,2,20,4,5,3,5,4
> ]
> Would it be possible to give more priority to the outgoing messages?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
