Mindmajix

Testing mod cluster

Having completed and verified the installation of mod cluster, we can now test it with minimal web application. The sample application packaged as balancer.war contains simply an index.jsp page, which dumps a message on the console.
<%
Integer counter = (Integer)session.getAttribute(“counter”);
if (counter == null) {
session.setAttribute(“counter”,new Integer(1));
}e
lse {
session.setAttribute(“counter”,new Integer(counter+1));
}S
ystem.out.println(“Counter”+session.getAttribute(“counter”));out.println(“Counter
“+session.getAttribute(“counter”));
%>
Now, open your browser and point to the httpd proxy address we have configured at:
http://192.168.10.1:8888/balancer

As you can see, mod cluster follows the sticky session policy; that is, once a session is started on one server, subsequent requests are sent to the same node:

Screenshot_3

Load-balancing between nodes

We will run one more test in order to verify how mod_cluster distributes the load between several different clients. For the purpose of our test, we will need a software that can launch a minimal amount of requests. We will use JMeter, which is a Java desktop application designed to load and test functional behavior and measure performance. JMeter can be downloaded from:

http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi.

In short, a JMeter test plan consists of one or more Thread groups, logic controllers, listeners, timers, assertions, and configuration elements. For the purpose of our example, we will just create the following elements:

  • A Thread Group, which is configured to run 100 subsequent requests
  • An HTTP Request element, which contains the information about the web application end point

Screenshot_4

Additionally, you should add a Listener element, which collects the test plan result in a table/graph in order to analyze it.

Now, from the top menu launch Run | Start and the JMeter test will be executed. Running the test demonstrates that the requests are roughly split between the two servers. As a matter of fact, an HTTP Request element, by default, treats every request as a single session that ends at the request.

Screenshot_5

Using load metrics

The built-in configuration of mod_cluster distributes requests using a fixed load factor. That is, it corresponds to the default configuration, which is:

<subsystem xmlns=”urn:jboss:domain:modcluster:1.0″>
<mod-cluster-config>
<simple-load-provider load=”1″/>
</mod-cluster-config>
</subsystem>
You can, however, customize the load-balancing using dynamic attributes, which are a set of metrics that can be included in a dynamic-load-provider element. For example:

<subsystem xmlns=”urn:jboss:domain:modcluster:1.0″>
<mod-cluster-config advertise-socket=”mod_cluster”>
<dynamic-load-provider history=”10″ decay=”2″>
<load-metric type=”cpu” weight=”2″ capacity=”1″/>
<load-metric type=”sessions” weight=”1″ capacity=”512″/>
</dynamic-load-provider>
</mod-cluster-config>
</subsystem>

The most important factors when computing load balancing are the weight and capacity properties. The weight (default is 1) indicates the impact of a metric with respect to the other metrics. In the previous example, the CPU metric will have twice the impact on the sessions that have a load factor metric of 1.

The capacity, on the other hand, can be used for a fine-grained control on the load metrics. By setting a different capacity to each metric, you can actually favor one node instead of another while preserving the metric weights.
The list of supported load metrics is resumed in the following table:

Screenshot_6

Screenshot_7

The above metrics can also be set using the CLI. For example, supposing that you want to add a metric that is based on the amount of heap used by the proxy. Here’s what you need to issue:

[standalone@192.168.10.1:9999 /] /subsystem=modcluster:addmetric(
type=heap)
{“outcome” => “success”}
[standalone@192.168.10.1:9999 /] /subsystem=modcluster:readresource(
name=mod-clu
ster-config)
{
“outcome” => “success”,
“result” => {
“advertise-socket” => “modcluster”,
“dynamic-load-provider” => {
“history” => 9,
“decay” => 2,
“load-metric” => [{
“address” => “[(\”subsystem\” => \”modcluster\”)]”,
“operation” => “add-metric”,
“type” => “heap”
}

]

}
}
}
At any time, the metric can be removed using the remove-metric command:
[standalone@192.168.10.1:9999 /] /subsystem=modcluster:removemetric(
type=heap)
{“outcome” => “success”}


0 Responses on Testing mod cluster"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.