JBoss Testing Mod Cluster

Having completed and verified the installation of mod cluster, we can now test it with a minimal web application. The sample application packaged as balancer.war contains simply an index.jsp page, which dumps a message on the console.

Now, open your browser and point to the https proxy address we have configured at:
https://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:

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 endpoint.

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

Frequently asked Jboss Interview Questions

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.

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:

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:

The above metrics can also be set using the CLI. For example, suppose 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”}