March 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from MODIFIED to ON_QA > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Final > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from ASSIGNED to MODIFIED > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Final > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-168) mod_cluster should use hostname provided in address instead a IP address

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-168?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-168: -------------------------------------- Fix Version/s: 1.3.1.Final > mod_cluster should use hostname provided in address instead a IP address > ------------------------------------------------------------------------ > > Key: MODCLUSTER-168 > URL: https://issues.jboss.org/browse/MODCLUSTER-168 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.1.0.CR3 > Environment: any > Reporter: Jean-Frederic Clere > Assignee: Paul Ferraro > Fix For: 1.3.1.Final, 1.2.9.Final > > > The CONFIG message contains something like: > JVMRoute=51ec121e-2976-3d75-bfd9-9e662bbb4bcd&Host=10.33.144.3&Port=8009&Type=ajp > Even if the Connector is defined like: > <Connector port="8009" address= "jfcpc" protocol="AJP/1.3" redirectPort="8443" /> > There are 2 ways to fix: > - Use the String (Change the Connector.java in mod_cluster). > - Use parameters.put("Host", connector.getAddress().getHostName()); when building the CONFIG message. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-393) One can't change history and decay with DynamicLoadBalanceFactorProvider

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-393?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-393: ------------------------------------------- Np, I can take a look. > One can't change history and decay with DynamicLoadBalanceFactorProvider > ------------------------------------------------------------------------ > > Key: MODCLUSTER-393 > URL: https://issues.jboss.org/browse/MODCLUSTER-393 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Radoslav Husar > Priority: Critical > Attachments: redacted_log > > > I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*. > I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following: > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <dynamic-load-provider history="0"> > <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1"> > <property name="capacity" value="1000"/> > <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/> > <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> > </custom-load-metric> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work. > If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent > that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called. > The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles. > The same IMHO holds for the decay attribute. > Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]: > {code} > // Historical value contribute an exponentially decayed factor > for (int i = 0; i < queue.size(); ++i) { > double decay = 1 / Math.pow(decayFactor, i); > totalDecay += decay; > this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay)); > totalLoad += queue.get(i).doubleValue() * decay; > } > {code} > and > {code} > try { > // Normalize load with respect to capacity > this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity()); > this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString()); > totalWeight += weight; > totalWeightedLoad += this.average(metricLoadHistory) * weight; > } catch (Exception e) { > this.log.error(e.getLocalizedMessage(), e); > } > {code} > with the following being the output: [^redacted_log]. > So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from > {noformat} > KTAG metricLoadHistory:[0.8] > {noformat} > to > {noformat} > KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8] > {noformat} > which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-) > WDYT? -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-393) One can't change history and decay with DynamicLoadBalanceFactorProvider

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-393?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-393: ------------------------------------------- (Actually [~pferraro] is the author of the class in question, so I might have picked a wrong assignee...) > One can't change history and decay with DynamicLoadBalanceFactorProvider > ------------------------------------------------------------------------ > > Key: MODCLUSTER-393 > URL: https://issues.jboss.org/browse/MODCLUSTER-393 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Radoslav Husar > Priority: Critical > Attachments: redacted_log > > > I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*. > I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following: > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <dynamic-load-provider history="0"> > <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1"> > <property name="capacity" value="1000"/> > <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/> > <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> > </custom-load-metric> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work. > If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent > that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called. > The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles. > The same IMHO holds for the decay attribute. > Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]: > {code} > // Historical value contribute an exponentially decayed factor > for (int i = 0; i < queue.size(); ++i) { > double decay = 1 / Math.pow(decayFactor, i); > totalDecay += decay; > this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay)); > totalLoad += queue.get(i).doubleValue() * decay; > } > {code} > and > {code} > try { > // Normalize load with respect to capacity > this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity()); > this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString()); > totalWeight += weight; > totalWeightedLoad += this.average(metricLoadHistory) * weight; > } catch (Exception e) { > this.log.error(e.getLocalizedMessage(), e); > } > {code} > with the following being the output: [^redacted_log]. > So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from > {noformat} > KTAG metricLoadHistory:[0.8] > {noformat} > to > {noformat} > KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8] > {noformat} > which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-) > WDYT? -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from ON_QA to ASSIGNED > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Final > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-372) Number of registered contexts negatively affects mod_cluster performance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-372?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-372: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1030965|https://bugzilla.redhat.com/show_bug.cgi?id=1030965] from ON_QA to MODIFIED > Number of registered contexts negatively affects mod_cluster performance > ------------------------------------------------------------------------ > > Key: MODCLUSTER-372 > URL: https://issues.jboss.org/browse/MODCLUSTER-372 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final, 1.2.6.Final > Environment: RHEL6, other platforms are to be confirmed. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: mod_cluster, performace > Fix For: 1.3.0.Final, 1.2.8.Final > > Attachments: 4-workers-1-context-balancer-cpu.png, 4-workers-61-context-accessing-1-balancer-cpu.png, 9-workers-1-context-balancer-cpu.png, 9-workers-31-context-accessing-1-balancer-cpu.png, 9-workers-31-context-round-robin-balancer-cpu.png, callgrind.zip, httpd.conf > > > There is a performance concern regarding CPU usage on the Apache HTTP Server with mod_cluster set up as a load balancer. Perf tests revealed that the major variable affecting the CPU usage is the overall number of registered contexts. It's noteworthy that these contexts actually don't need to be accessed at all, it's enough that they are present. > The first test [9 workers, 31 contexts, round robin|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,31contexts,...] depicts a behavior where all contexts are being accessed in a round robin fashion. Note the CPU usage. If we compare it to the [9 workers, 1 context|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,1context] test, it becomes apparent that there is something wrong with the CPU usage. As it is clear from the [9 workers, 31 contexts, access 1|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,31contexts,acce...] test, accessing only one of these contexts doesn't help much. > The last two tests, [4 workers, 61 contexts, accessing 1|https://issues.jboss.org/browse/MODCLUSTER-372#4workers,61contexts,acce...] and [4 workers, 1 context|https://issues.jboss.org/browse/MODCLUSTER-372#4workers,1context] confirm the results, environment differs only in number of nodes and number of contexts. > [^httpd.conf] attached, stay tuned for some profiler outputs... > h3. 9 workers, 31 contexts, round robin > !9-workers-31-context-round-robin-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8843|147.4|15|60|0|8843|100%| > |9|250|250|14422|240.3|37|215|0|14422|100%| > |9|350|350|17551|292.5|196|443|0|17551|100%| > |9|450|450|21303|355.0|269|603|0|21303|100%| > |9|550|550|24818|413.6|325|686|0|24818|100%| > |9|650|650|26804|446.7|469|800|0|26804|100%| > |9|750|750|29930|498.8|507|985|0|29930|100%| > |9|850|850|30665|511.0|665|1185|0|30665|100%| > |9|950|950|34421|573.6|647|1316|0|34421|100%| > |9|1050|1050|35067|584.4|800|1487|0|35067|100%| > |9|1150|1150|36024|600.4|925|1612|0|36024|100%| > |9|1250|1250|36635|610.5|1030|1815|0|36635|100%| > |9|1350|1350|38395|639.9|1096|1942|0|38395|100%| > |9|1450|1450|39713|661.8|1170|2466|0|39713|100%| > |9|1550|1550|39455|657.5|1392|2340|0|39455|100%| > |9|1650|1650|39849|664.1|1465|4240|0|39849|100%| > |9|1750|1750|42435|707.2|1454|6511|0|42435|100%| > |9|1850|1850|44714|745.2|1498|4866|0|44714|100%| > |9|1950|1911|46072|767.8|1554|43016|0|46072|100%| > |9|2050|1911|44496|741.5|1617|4953|39|44457|99%| > |9|2150|1911|43715|728.5|1632|5348|125|43590|99%| > |9|2250|1911|41112|685.1|1764|9800|155|40957|99%| > h3. 9 workers, 31 contexts, accessing only one of them > !9-workers-31-context-accessing-1-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8954|149.2|4|42|0|8954|100%| > |9|250|250|14897|248.3|7|33|0|14897|100%| > |9|350|350|20784|346.4|8|68|0|20784|100%| > |9|450|450|26748|445.8|8|69|0|26748|100%| > |9|550|550|32553|542.5|11|92|0|32553|100%| > |9|650|650|38558|642.6|10|60|0|38558|100%| > |9|750|750|43571|726.1|29|329|0|43571|100%| > |9|850|850|46133|768.8|99|494|0|46133|100%| > |9|950|950|50854|847.5|120|501|0|50854|100%| > |9|1050|1050|54451|907.4|154|584|0|54451|100%| > |9|1150|1150|59961|999.3|138|674|0|59961|100%| > |9|1250|1250|62567|1,042.6|198|675|0|62567|100%| > |9|1350|1350|61939|1,032.2|301|799|0|61939|100%| > |9|1450|1450|67920|1,131.9|276|844|0|67920|100%| > |9|1550|1550|73151|1,219.1|261|861|0|73151|100%| > |9|1650|1650|73937|1,232.2|332|955|0|73937|100%| > |9|1750|1750|73516|1,225.2|423|1046|0|73516|100%| > |9|1850|1850|72556|1,209.1|515|1264|0|72556|100%| > |9|1950|1911|78613|1,310.1|454|50273|0|78613|100%| > |9|2050|1911|80141|1,335.6|431|1225|39|80102|99%| > |9|2150|1911|76979|1,282.9|490|1338|127|76852|99%| > |9|2250|1911|78048|1,300.7|464|1305|136|77912|99%| > h3. 9 workers, 1 context > !9-workers-1-context-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8965|149.4|2|12|0|8965|100%| > |9|250|250|14965|249.4|2|22|0|14965|100%| > |9|350|350|20950|349.1|2|23|0|20950|100%| > |9|450|450|26941|449.0|2|26|0|26941|100%| > |9|550|550|32937|548.9|1|26|0|32937|100%| > |9|650|650|38900|648.3|1|19|0|38900|100%| > |9|750|750|44918|748.6|1|11|0|44918|100%| > |9|850|850|50902|848.3|2|22|0|50902|100%| > |9|950|950|56878|947.9|1|14|0|56878|100%| > |9|1050|1050|62874|1,047.8|2|12|0|62874|100%| > |9|1150|1150|68845|1,147.3|2|99|0|68845|100%| > |9|1250|1250|74851|1,247.4|2|103|0|74851|100%| > |9|1350|1350|80826|1,347.0|2|100|0|80826|100%| > |9|1450|1450|86806|1,446.7|2|19|0|86806|100%| > |9|1550|1550|92817|1,546.8|2|52|0|92817|100%| > |9|1650|1650|98774|1,646.1|2|18|0|98774|100%| > |9|1750|1750|104755|1,745.8|2|18|0|104755|100%| > |9|1850|1850|110734|1,845.4|2|20|0|110734|100%| > |9|1950|1910|113419|1,890.2|9|41855|0|113419|100%| > |9|2050|1911|114437|1,907.1|2|77962|39|114397|99%| > |9|2150|1911|114481|1,907.9|2|15|128|114353|99%| > |9|2250|1911|114545|1,908.9|2|24|144|114401|99%| > h3. 4 workers, 61 contexts, accessing only one of them > !4-workers-61-context-accessing-1-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |4|500|500|29796|496.6|6|52|0|29796|100%| > |4|650|650|38706|645.0|7|149|0|38706|100%| > |4|800|800|47585|793.0|8|129|0|47585|100%| > |4|950|950|54467|907.7|43|377|0|54467|100%| > |4|1100|1100|62500|1,041.6|54|396|0|62500|100%| > |4|1250|1250|69446|1,157.3|81|512|0|69446|100%| > |4|1400|1400|76217|1,270.2|97|517|0|76217|100%| > |4|1550|1550|80216|1,336.8|152|810|0|80216|100%| > |4|1700|1700|80797|1,346.5|271|864|0|80797|100%| > |4|1850|1850|94172|1,569.3|182|822|0|94172|100%| > |4|2000|1916|91014|1,516.8|253|48650|0|91014|100%| > |4|2150|1916|95852|1,597.4|205|848|83|95769|99%| > h3. 4 workers, 1 context > !4-workers-1-context-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |4|500|500|29922|498.7|2|39|0|29922|100%| > |4|650|650|38923|648.7|1|39|0|38923|100%| > |4|800|800|47916|798.5|1|17|0|47916|100%| > |4|950|950|56896|948.2|1|17|0|56896|100%| > |4|1100|1100|65889|1,098.1|1|115|0|65889|100%| > |4|1250|1250|74874|1,247.8|1|101|0|74874|100%| > |4|1400|1400|83818|1,396.8|1|17|0|83818|100%| > |4|1550|1550|92830|1,547.0|1|17|0|92830|100%| > |4|1700|1700|101805|1,696.6|1|11|0|101805|100%| > |4|1850|1850|110785|1,846.3|1|11|0|110785|100%| > |4|2000|1916|113747|1,895.6|10|53108|0|113747|100%| > |4|2150|1916|114825|1,913.6|1|24|83|114742|99%| -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-372) Number of registered contexts negatively affects mod_cluster performance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-372?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-372: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1030965|https://bugzilla.redhat.com/show_bug.cgi?id=1030965] from MODIFIED to ON_QA > Number of registered contexts negatively affects mod_cluster performance > ------------------------------------------------------------------------ > > Key: MODCLUSTER-372 > URL: https://issues.jboss.org/browse/MODCLUSTER-372 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final, 1.2.6.Final > Environment: RHEL6, other platforms are to be confirmed. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: mod_cluster, performace > Fix For: 1.3.0.Final, 1.2.8.Final > > Attachments: 4-workers-1-context-balancer-cpu.png, 4-workers-61-context-accessing-1-balancer-cpu.png, 9-workers-1-context-balancer-cpu.png, 9-workers-31-context-accessing-1-balancer-cpu.png, 9-workers-31-context-round-robin-balancer-cpu.png, callgrind.zip, httpd.conf > > > There is a performance concern regarding CPU usage on the Apache HTTP Server with mod_cluster set up as a load balancer. Perf tests revealed that the major variable affecting the CPU usage is the overall number of registered contexts. It's noteworthy that these contexts actually don't need to be accessed at all, it's enough that they are present. > The first test [9 workers, 31 contexts, round robin|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,31contexts,...] depicts a behavior where all contexts are being accessed in a round robin fashion. Note the CPU usage. If we compare it to the [9 workers, 1 context|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,1context] test, it becomes apparent that there is something wrong with the CPU usage. As it is clear from the [9 workers, 31 contexts, access 1|https://issues.jboss.org/browse/MODCLUSTER-372#9workers,31contexts,acce...] test, accessing only one of these contexts doesn't help much. > The last two tests, [4 workers, 61 contexts, accessing 1|https://issues.jboss.org/browse/MODCLUSTER-372#4workers,61contexts,acce...] and [4 workers, 1 context|https://issues.jboss.org/browse/MODCLUSTER-372#4workers,1context] confirm the results, environment differs only in number of nodes and number of contexts. > [^httpd.conf] attached, stay tuned for some profiler outputs... > h3. 9 workers, 31 contexts, round robin > !9-workers-31-context-round-robin-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8843|147.4|15|60|0|8843|100%| > |9|250|250|14422|240.3|37|215|0|14422|100%| > |9|350|350|17551|292.5|196|443|0|17551|100%| > |9|450|450|21303|355.0|269|603|0|21303|100%| > |9|550|550|24818|413.6|325|686|0|24818|100%| > |9|650|650|26804|446.7|469|800|0|26804|100%| > |9|750|750|29930|498.8|507|985|0|29930|100%| > |9|850|850|30665|511.0|665|1185|0|30665|100%| > |9|950|950|34421|573.6|647|1316|0|34421|100%| > |9|1050|1050|35067|584.4|800|1487|0|35067|100%| > |9|1150|1150|36024|600.4|925|1612|0|36024|100%| > |9|1250|1250|36635|610.5|1030|1815|0|36635|100%| > |9|1350|1350|38395|639.9|1096|1942|0|38395|100%| > |9|1450|1450|39713|661.8|1170|2466|0|39713|100%| > |9|1550|1550|39455|657.5|1392|2340|0|39455|100%| > |9|1650|1650|39849|664.1|1465|4240|0|39849|100%| > |9|1750|1750|42435|707.2|1454|6511|0|42435|100%| > |9|1850|1850|44714|745.2|1498|4866|0|44714|100%| > |9|1950|1911|46072|767.8|1554|43016|0|46072|100%| > |9|2050|1911|44496|741.5|1617|4953|39|44457|99%| > |9|2150|1911|43715|728.5|1632|5348|125|43590|99%| > |9|2250|1911|41112|685.1|1764|9800|155|40957|99%| > h3. 9 workers, 31 contexts, accessing only one of them > !9-workers-31-context-accessing-1-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8954|149.2|4|42|0|8954|100%| > |9|250|250|14897|248.3|7|33|0|14897|100%| > |9|350|350|20784|346.4|8|68|0|20784|100%| > |9|450|450|26748|445.8|8|69|0|26748|100%| > |9|550|550|32553|542.5|11|92|0|32553|100%| > |9|650|650|38558|642.6|10|60|0|38558|100%| > |9|750|750|43571|726.1|29|329|0|43571|100%| > |9|850|850|46133|768.8|99|494|0|46133|100%| > |9|950|950|50854|847.5|120|501|0|50854|100%| > |9|1050|1050|54451|907.4|154|584|0|54451|100%| > |9|1150|1150|59961|999.3|138|674|0|59961|100%| > |9|1250|1250|62567|1,042.6|198|675|0|62567|100%| > |9|1350|1350|61939|1,032.2|301|799|0|61939|100%| > |9|1450|1450|67920|1,131.9|276|844|0|67920|100%| > |9|1550|1550|73151|1,219.1|261|861|0|73151|100%| > |9|1650|1650|73937|1,232.2|332|955|0|73937|100%| > |9|1750|1750|73516|1,225.2|423|1046|0|73516|100%| > |9|1850|1850|72556|1,209.1|515|1264|0|72556|100%| > |9|1950|1911|78613|1,310.1|454|50273|0|78613|100%| > |9|2050|1911|80141|1,335.6|431|1225|39|80102|99%| > |9|2150|1911|76979|1,282.9|490|1338|127|76852|99%| > |9|2250|1911|78048|1,300.7|464|1305|136|77912|99%| > h3. 9 workers, 1 context > !9-workers-1-context-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |9|150|150|8965|149.4|2|12|0|8965|100%| > |9|250|250|14965|249.4|2|22|0|14965|100%| > |9|350|350|20950|349.1|2|23|0|20950|100%| > |9|450|450|26941|449.0|2|26|0|26941|100%| > |9|550|550|32937|548.9|1|26|0|32937|100%| > |9|650|650|38900|648.3|1|19|0|38900|100%| > |9|750|750|44918|748.6|1|11|0|44918|100%| > |9|850|850|50902|848.3|2|22|0|50902|100%| > |9|950|950|56878|947.9|1|14|0|56878|100%| > |9|1050|1050|62874|1,047.8|2|12|0|62874|100%| > |9|1150|1150|68845|1,147.3|2|99|0|68845|100%| > |9|1250|1250|74851|1,247.4|2|103|0|74851|100%| > |9|1350|1350|80826|1,347.0|2|100|0|80826|100%| > |9|1450|1450|86806|1,446.7|2|19|0|86806|100%| > |9|1550|1550|92817|1,546.8|2|52|0|92817|100%| > |9|1650|1650|98774|1,646.1|2|18|0|98774|100%| > |9|1750|1750|104755|1,745.8|2|18|0|104755|100%| > |9|1850|1850|110734|1,845.4|2|20|0|110734|100%| > |9|1950|1910|113419|1,890.2|9|41855|0|113419|100%| > |9|2050|1911|114437|1,907.1|2|77962|39|114397|99%| > |9|2150|1911|114481|1,907.9|2|15|128|114353|99%| > |9|2250|1911|114545|1,908.9|2|24|144|114401|99%| > h3. 4 workers, 61 contexts, accessing only one of them > !4-workers-61-context-accessing-1-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |4|500|500|29796|496.6|6|52|0|29796|100%| > |4|650|650|38706|645.0|7|149|0|38706|100%| > |4|800|800|47585|793.0|8|129|0|47585|100%| > |4|950|950|54467|907.7|43|377|0|54467|100%| > |4|1100|1100|62500|1,041.6|54|396|0|62500|100%| > |4|1250|1250|69446|1,157.3|81|512|0|69446|100%| > |4|1400|1400|76217|1,270.2|97|517|0|76217|100%| > |4|1550|1550|80216|1,336.8|152|810|0|80216|100%| > |4|1700|1700|80797|1,346.5|271|864|0|80797|100%| > |4|1850|1850|94172|1,569.3|182|822|0|94172|100%| > |4|2000|1916|91014|1,516.8|253|48650|0|91014|100%| > |4|2150|1916|95852|1,597.4|205|848|83|95769|99%| > h3. 4 workers, 1 context > !4-workers-1-context-balancer-cpu.png|thumbnail! > ||Nodes||Sessions||Ses.Active||Samples||samples/s||mean resp. ms||max resp. ms||conn. errors||valid samples||%|| > |4|500|500|29922|498.7|2|39|0|29922|100%| > |4|650|650|38923|648.7|1|39|0|38923|100%| > |4|800|800|47916|798.5|1|17|0|47916|100%| > |4|950|950|56896|948.2|1|17|0|56896|100%| > |4|1100|1100|65889|1,098.1|1|115|0|65889|100%| > |4|1250|1250|74874|1,247.8|1|101|0|74874|100%| > |4|1400|1400|83818|1,396.8|1|17|0|83818|100%| > |4|1550|1550|92830|1,547.0|1|17|0|92830|100%| > |4|1700|1700|101805|1,696.6|1|11|0|101805|100%| > |4|1850|1850|110785|1,846.3|1|11|0|110785|100%| > |4|2000|1916|113747|1,895.6|10|53108|0|113747|100%| > |4|2150|1916|114825|1,913.6|1|24|83|114742|99%| -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from MODIFIED to ON_QA > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Final > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-365: ---------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1050223|https://bugzilla.redhat.com/show_bug.cgi?id=1050223] from POST to MODIFIED > Reset MCMPs are sent to all available proxies > --------------------------------------------- > > Key: MODCLUSTER-365 > URL: https://issues.jboss.org/browse/MODCLUSTER-365 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Labels: mod_cluster > Fix For: 1.2.7.Final, 1.3.0.Final > > > Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design. > This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario. -- 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

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2014