Load generating modes

Section describes different load generation configurations of the framework

• Simplest configuration
• Default configuration
• Distributed configuration
• Run framework in the distributed configuration
• Distributed configuration test flow

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

• download java archetype
• configure `environment.properties` file in the java project to use H2 DB
• compile and run test project

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

• Results storage and representation components are always running in the docker containers
• When you compile and run test project, all load generating components are executed in a single JVM. During test run all results are collected in the test results DB. Later you can access results via web interface or REST API. RESP API also allows to download pdf report.
• Optionally: you can start one or many monitoring agents to collect system and JVM metrics. All monitoring metrics will be also stored in the results DB
• Optionally: via jagger properties you can enable communication between load generating components and JaaS. In this case you will be able to submit and start new test project to already running load generating components via REST API

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

• Results storage and representation components are always running
• Run framework in the distributed configuration
• During test run all results are collected in the test results DB. Later you can access results via web interface or REST API. RESP API also allows to download pdf report.
• Optionally: you can start one or many monitoring agents to collect system and JVM metrics. All monitoring metrics will be also stored in the results DB
• Optionally: via jagger properties you can enable communication between load generating components and JaaS. In this case you will be able to submit and start new test project to already running load generating components via REST API

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.roles=KERNEL
  -Dchassis.coordination.bean=zookeeperCoordinator
  -Dchassis.coordinator.zookeeper.endpoint={master/coordinator host}:2181
  -Dchassis.storage.fs.default.name=hdfs://{master/coordinator host}/
  -Dchassis.workspace=./jaggerworkspace/server

• 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.roles=MASTER,COORDINATION_SERVER,HTTP_COORDINATION_SERVER
  -Dchassis.conditions.monitoring.enable=true
  -Dchassis.conditions.min.agents.count=1
  -Dchassis.conditions.min.kernels.count=1
  -Dchassis.coordination.bean=zookeeperCoordinator
  -Dchassis.coordinator.zookeeper.endpoint={master/coordinator host}:2181
  -Dchassis.log.storage.bean=hdfsStorage
  -Dchassis.storage.fs.default.name=hdfs://{master/coordinator host}/
  -Dchassis.workspace=./jaggerworkspace/server

• Start Agent

  ./start_agent.sh
  -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