Gatling Plugin for Gradle
Installation
Follow the steps described at Gradle Plugin Portal page.
- Java 8 Upgrade
-
-
Due to a bug Gatling 2.2.0 is supported only from gradle-gatling-plugin version 0.3.0
-
JDK 8 is required for Gatling 2.2.0, so this plugin is also require JDK8
-
For whatever reason you stuck with JDK 7, please keep using the 0.2.x series of this plugin.
Project Layout
Folders overview
The plugin uses src/gatling
as its source root.
There are several folders serving different purposes under the source root.
-
Simulation sources direcrory
-
Feeder data directory
-
Request bodies directory
-
Configuration directory
This plugin supports two project layouts.
-
Standard Gradle/Maven layout
-
Gatling-like layout
There’s no need to explicitly setup any of those. Plugin auto-detects layout during examination of project’s folder structure.
Standard Gradle/Maven layout
Directory | Purpose |
---|---|
|
Simulation sources |
|
Feeder data |
|
Request bodies |
|
Configuration |
Gatling-like layout
Directory | Purpose |
---|---|
|
Simulation sources |
|
Feeder data |
|
Request bodies |
|
Configuration |
Plugin configuration
The plugin defines the following extension properties in the gatling
closure
Property name | Type | Default value | Description |
---|---|---|---|
toolVersion |
String |
'2.3.1' |
|
logLevel |
String |
'WARN' |
The default Gatling console log level if no |
scalaVersion |
String |
'2.12.3' |
|
jvmArgs |
List<String> |
['-server', '-Xmx1G',
'-XX:+UseG1GC', '-XX:MaxGCPauseMillis=30',
'-XX:G1HeapRegionSize=16m',
'-XX:InitiatingHeapOccupancyPercent=75',
'-XX:+ParallelRefProcEnabled',
'-XX:+PerfDisableSharedMem',
'-XX:+AggressiveOpts',
'-XX:+OptimizeStringConcat',
'-XX:+HeapDumpOnOutOfMemoryError',
'-Djava.net.preferIPv4Stack=true',
'-Djava.net.preferIPv6Addresses=false'] |
Additional arguments passed to JVM when executing |
simulations |
Closure or Iterable<String> |
{ include "**/*Simulation.scala" } |
Simulations filter. |
Custom source folder
If you have a special layout you can configure the source root folder and all gatling specific folders. Currently you have to set the source sets accordingly.
+
project.sourceSets {
gatling {
scala.srcDirs = ['src/test/gatling']
resources.srcDirs = ['src/test/gatling/user-files/simulations', 'src/test/gatling/user-files/data', 'src/test/gatling/user-files/body', 'src/test/gatling/conf']
}
}
gatling {
sourceRoot = 'src/test/gatling'
simulationsDir = 'user-files/simulations' (1)
dataDir = 'user-files/data' (2)
bodiesDir = 'user-files/bodies' (3)
confDir = 'conf' (4)
}
-
the plugin looks for simulations in
src/test/gatling/user-files/simulations
-
data is located in
src/test/gatling/user-files/data
-
request bodies are be placed in
src/test/gatling/user-files/bodies
-
gatling configuration is located in
src/test/gatling/conf
Examples
- Overriding Gatling version and JVM arguments
-
gatling { toolVersion = '2.3.1' jvmArgs = [ '-server', '-Xms512M', '-Xmx512M' ] }
- Filtering simulations using FQN list
-
gatling { simulations = [ 'com.package1.MySimu', 'com.package2.advanced.MySimulation' ] (1) }
-
only execute
com.package1.MySimu
andcom.package2.advanced.MySimulation
simulations.
-
- Filtering simulations using Groovy closure
-
gatling { simulations = { include "**/package1/*Simu.scala" (1) include "**/package2/*Simulation.scala" (2) } }
-
all
Scala
files from plugin simulation dir subfolderpackage1
ending withSimu
. -
all
Scala
files from plugin simulation dir subfolderpackage2
ending withSimulation
.
-
Logging
Gatling
uses logback
to customize its output.
To change logging behaviour, put your logback.xml
into configuration folder,
i.e. src/gatling/resources/conf
or src/gatling/conf
depending on choosen project layout.
If no custom logback.xml
provided,
by default plugin will implicitly use following configuration.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
<immediateFlush>false</immediateFlush>
</encoder>
</appender>
<root level="${logLevel}"> (1)
<appender-ref ref="CONSOLE"/>
</root>
</configuration>
-
logLevel
is configured via plugin extension,WARN
by default.
Dependency Management
This plugin defines three configurations gatling
, gatlingCompile
and gatlingRuntime
.
By default plugin adds Gatling
libraries to gatling
configuration.
Configurations gatlingCompile
and gatlingRuntime
extend gatling
, i.e. all dependencies declared in gatling
will be inherited.
Also project classes (src/main
) and tests classes (src/test
) are added to gatlingCompile
and gatlingRuntime
classpath,
so you can reuse existing production and test code in your simulations.
Additional dependencies can be added by plugin’s users to any of configurations mentioned above.
- Example
dependencies {
gatling 'com.google.code.gson:gson:2.8.0' (1)
gatlingCompile 'org.apache.commons:commons-lang3:3.4' (2)
gatlingRuntime 'cglib:cglib-nodep:3.2.0' (3)
}
-
adding
gson
library, available both in compile and runtime classpath. -
adding
commons-lang3
to compile classpath for simulations. -
adding
cglib
to runtime classpath for simulations.
Tasks
Plugin provides dedicated task GatlingRunTask
that is responsible for execute gatling simulations.
Customer may create instances of this task to execue particular simulations.
Task extends Gradle’s JavaExec
task.
Default tasks
Additionally plugin creates several default tasks
Task name | Type | Description |
---|---|---|
|
- |
Compiles |
|
GatlingRunTask |
Executes all |
|
GatlingRunTask |
Executes single |
Examples
- Run all simulations
-
$ gradle gatlingRun
- Run single simulation implemented in
com.project.simu.MySimulation
class -
$ gradle gatlingRun-com.project.simu.MySimulation
Troubleshooting and known issues
Spring Boot and Netty version
Caused by io.spring.dependency-management
plugin and Spring platform BOM files.
The dependency management plugin ensures that all declared dependencies have exactly the same versions as declared in BOM.
Since Spring Boot
declares own Netty
version (e.g. 4.1.22.Final
) - this version is applied globally
for all the configurations of the Gradle
project, even if configuration doesn’t use Spring
.
There’s 2 ways of solving the problem, depending on the actual usage of Netty
in the project
-
When production code doesn’t rely on
Netty
ext['netty.version'] = '4.0.51.Final'
This declares Netty
version globally for all transitive dependencies in your project, including Spring
.
-
When production code uses
Netty
dependencyManagement {
gatling {
dependencies {
dependencySet(group: 'io.netty', version: '4.0.51.Final') {
entry 'netty-codec-http'
entry 'netty-codec'
entry 'netty-handler'
entry 'netty-buffer'
entry 'netty-transport'
entry 'netty-common'
entry 'netty-transport-native-epoll'
}
}
}
}
This options ensures that 4.0.51.Final
will be used only for gatling
configurations, leaving other dependencies unchanged.