All Classes Namespaces Files Functions Variables Enumerator Groups Pages
Load generating modes

Section describes different load generation configurations of the framework

Configuration of the framework is provided via property files or system properties

Simplest configuration

In the simplest configuration you can launch framework as a single JVM

In this case all load generating components are executed in a single JVM. You will collect standard performance metrics. Pdf report will be generated at the end of the test execution

Simplest configuration of the test framework

Default configuration

After running local installation, you will get default framework configuration, like shown in the image below.
In this case

Default configuration of the test framework

Distributed configuration

In case when single node is not enough to generate enough load, or you would like to load your system from different nodes/locations, you can run framework in the distributed mode.

In distributed mode, load generators (Kernels) are started as separate java applications on the single or multiple nodes. Kernels are responsible for communication with the SUT, with monitoring agents and for temporary storage of the raw test results.

Master/Coordinator is started in it's own JVM and is responsible for load balancing between Kernels, communication with JaaS, final results aggregation and storage in the results DB.
In this case

Distributed configuration of the test framework

Run framework in the distributed configuration

Already in the single node mode Jagger framework is capable of producing high load: thousands of virtual users with thousands of transactions per seconds. Usually these numbers are limited by the system resources
When such load is not enough, you can run framework in the distributed mode on multiple nodes like on the image below

Execution in the distributed mode

Next roles are available in the distributed mode:

  • one instance with Master/Coordinator role
  • one or multiple instances with Kernel role

Master doesn't have information about Kernels that will do workload before its start. Kernel has an address of Master/Coordinator chassis.coordinator.zookeeper.endpoint in it's config and registers on Master/Coordinator after start. Master/Coordinator gets the list of registered Kernels and distributes tasks for execution among them. Report with execution results is available on Master after execution finished.

In order to start Jagger in the distributed mode.

  • Start Kernel(s)
    ./start.sh profiles/basic/environment.properties
    -Dchassis.coordinator.zookeeper.endpoint={master/coordinator host}:2181
    -Dchassis.storage.fs.default.name=hdfs://{master/coordinator host}/
  • Start Master In our case we will have one Kernels and one monitoring agent. Number of kernels and agents is not limited
    ./start.sh profiles/basic/environment.properties
    -Dchassis.coordinator.zookeeper.endpoint={master/coordinator host}:2181
    -Dchassis.storage.fs.default.name=hdfs://{master/coordinator host}/
  • Start Agent
    -Dchassis.coordination.http.url=http://{master/coordinator host}:8089
    -Djmx.enabled=false -Dagent.name=agentName

You can start Master, Kernel, Agent nodes in any order
Please remove ./jaggerworkspace folder in the directory if exists before starting nodes
Information about mentioned properties you can find in the Jagger configuration chapter

We are recommending to use Jenkins deployment plugin to start framework in the distributed mode in CI

Distributed configuration test flow

Distributed configuration test flow