ClusterBench is a simple application that can be deployed in a cluster of JBoss AS 7 (EAP 6), WildFly 8 and newer. Once deployed it is easy to stress (using JMeter, curl, etc.) and monitor the performance of the cluster while at the same time it can be easily checked the correctness of replicated sessions.
Branch | WildFly Version | Tomcat Version | EE Version(s) | Base JDK |
---|---|---|---|---|
|
34 |
10.1 |
Jakarta EE 10 |
11 |
|
33 |
10.1 |
Jakarta EE 10 |
11 |
|
32 |
10.1 |
Jakarta EE 10 |
11 |
|
31 |
10.1 |
Jakarta EE 10 |
11 |
|
30 |
10.1 |
Jakarta EE 10 |
11 |
|
29 |
10.1 |
Jakarta EE 10 |
11 |
|
28 |
10.1 |
Jakarta EE 10 |
11 |
|
27 |
10.1 |
Jakarta EE 10 |
11 |
|
26 (and previous) |
Java EE 5, EE 6, EE 7, EE 8 |
8 |
Clone the Git repository first and switch to its directory:
git clone https://github.com/clusterbench/clusterbench.git
Build the default main
branch to build the latest Jakarta EE 10 version:
mvn clean install
Output files:
./clusterbench-ee10-ear/target/clusterbench-ee10.ear
You can also use wildfly-maven-plugin
to run a container with the project already deployed.
It will also provision the server without having to download anything manually.
mvn clean wildfly:run
and navigate your browser to http://localhost:8080/clusterbench/.
You can use the deploy
goal of the WildFly Maven Plugin to deploy to your running instance by running:
mvn wildfly:deploy
which will deploy the resulting EAR to the running server.
To do this manually, copy clusterbench-ee10.ear
to server’s deployments directory
and start the standalone server in the HA mode:
cd ~/wildfly-32.0.0.Final cp ~/clusterbench/clusterbench-ee10-ear/target/clusterbench-ee10.ear standalone/deployments/ ./bin/standalone.sh -c standalone-ha.xml
You can also use the CLI to do so by starting the server, connecting with CLI and using deploy
command:
cd ~/wildfly-32.0.0.Final ./bin/standalone.sh -c standalone-ha.xml
Then connect with the CLI:
./bin/jboss-cli.sh -c [standalone@localhost:9990 /] deploy ~/clusterbench/clusterbench-ee10-ear/target/clusterbench-ee10.ear
If you prefer GUI, you can start the server and navigate to http://localhost:9990/ and follow the instructions.
To deploy the Tomcat variant of ClusterBench, copy the following war
file into Tomcat installation webapps/
directory
renaming it accordingly to the desired context, typically to clusterbench.war
to correspond with the context path on WildFly.
cp ~/git/clusterbench/clusterbench-ee10-web/target/clusterbench-ee10-web-tomcat.war webapps/clusterbench.war
Note that CDI, EJB, JSF, granular, and debug servlets are unsupported on Tomcat and not bundled in the war
.
That makes the session servlet the only one available for performance benchmarking.
First, make sure you have oc
and helm
installed. Now, log into OpenShift using the following
replacing with your token and server address:
oc login --token=sha256~<your_token> --server=https://api.sandbox-m3.1530.p1.openshiftapps.com:6443
First add the WildFly helm repo:
helm repo add wildfly https://docs.wildfly.org/wildfly-charts/
Now install the helm
chart:
helm install clusterbench-from-chart -f charts/helm.yaml wildfly/wildfly
You can watch the build using oc
:
oc get build -w
Once built, watch the deployment using:
oc get deployment clusterbench-from-chart -w
Once deployed, you can access the application for example the debug servlet using curl
:
[rhusar@ribera clusterbench]$ curl https://$(oc get route clusterbench-from-chart --template='{{ .spec.host }}')/clusterbench/debug ... Serial: 0 Session ID: nPw9NzEmPaZHlj0eYoCapZfBBOnNk_5HXNpq2Qi_ Current time: Wed Mar 22 14:36:52 GMT 2023
Once finished, remove everything using:
helm uninstall clusterbench-from-chart
Each servlet stresses a different replication logic, but they all produce the same reply:
number of times (integer) the servlet has been previously invoked within the existing session in a text/plain
response.
In other words, the first request returns 0 and each following invocation returns number incremented by 1.
Furthermore, each HTTP session carries 4 KB of dummy session data in a byte array.
The 'default' servlet. Stores serial number and data in SerialBean
object (POJO) which is directly stored in jakarta.servlet.http.HttpSession
.
Stores a serial number in @jakarta.enterprise.context.SessionScoped
bean.
Stores serial and data in @jakarta.ejb.Stateful
Jakarta Enterprise Bean (SFSB). The JEB is then invoked on every request.
Stores serial number and data separately and are both directly put to jakarta.servlet.http.HttpSession
.
The byte array is never changed and thus can be used to test the efficiency of using granular session replication.
Caution
|
The server configuration in use must be configured with ATTRIBUTE session granularity!
|
There are also two oad generating Servlets for memory and CPU usage. These Servlets simulate load on the target system. These can be used to test the load-balancing mechanism of the reverse proxy.
Servlet simulating CPU load of the cluster node. Parameters are milliseconds
(duration) and threads
.
Servlet that prints out useful information such as: the request headers, URI, query string, path info, serial (does create a session), session ID, time, server and local ports, node name, parameters, and cluster address/coordinator/members/physical addresses.
Servlet which allows to customize the HTTP status response code. Requires mandatory integer code
parameter.
Servlet which prints out the node name as a value of the jboss.node.name
system property.
The /scripts
directory contains CLI scripts for reconfiguring the application server for specific test scenarios:
Script | Description |
---|---|
infinispan-session-management-attribute.cli |
Reconfigures the default session manager to use |
infinispan-session-management-offload-attribute.cli |
Reconfigures the default session manager to use cache |
infinispan-session-management-offload-session.cli |
Reconfigures the default session manager to use cache |
There a several profiles to test specific scenarios where the standard build needs to be modified.
This profile produces a build to tests a shared sessions scenario where two WARs in the same EAR share HTTP sessions:
mvn install -P shared-sessions -DskipTests
This profile produces a build to tests a singleton deployment scenario where one EAR guaranteed to be active on a single node at a time:
mvn install -P singleton-deployment-specific-descriptor -DskipTests
Note
|
this version uses descriptor singleton-deployment.xml to achieve singleton-deployment functionality
|
This profile produces a build to tests a singleton deployment scenario where one EAR guaranteed to be active on a single node at a time:
mvn install -P singleton-deployment-jboss-all -DskipTests
Note
|
this version uses descriptor jboss-all.xml to achieve singleton-deployment functionality
|
Used in order to shorten name of bundled JARs and WARs within the final EAR file. Usually used in database tests to produce database tables with short names.
mvn clean install -P short-names -DskipTests
The default payload size can be overridden by a system property specifying integer number of bytes to use in a payload:
./bin/standalone.sh -c standalone-ha.xml -Dorg.jboss.test.clusterbench.cargokb=5
NoteEnsure identical value is specified for all containers in the cluster!
File new issues using GitHub Issues:
Contributions are welcome! Submit pull requests against the upstream repository on GitHub. Please follow the coding standards to keep the application simple and clean.
Project is licensed under Apache License Version 2.0.
Happy benchmarking!