⚙️ Configuration
You can configure your load test by the CLI options or a config file. Config file supports more features than the CLI. For example, you can't create a scenario-based load test with CLI options.
CLI Flags
ddosify [FLAG]
Flag | Description | Type | Default | Required |
---|---|---|---|---|
-t | Target website URL. Example: https://getanteon.com | string | - | Yes |
-n | Total iteration count | int | 100 | No |
-d | Test duration in seconds. | int | 10 | No |
-m | Request method. Available methods for HTTP(s) are GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS | string | GET | No |
-b | The payload of the network packet. AKA body for the HTTP. | string | - | No |
-a | Basic authentication. Usage: -a username:password | string | - | No |
-h | Headers of the request. You can provide multiple headers with multiple -h flag. Usage: -h 'Accept: text/html' | string | - | No |
-T | Timeout of the request in seconds. | int | 5 | No |
-P | Proxy address as host:port. -P 'http://user:pass@proxy_host.com:port' | string | - | No |
-o | Test result output destination. Supported outputs are [stdout, stdout-json] Other output types will be added. | string | stdout | No |
-l | Type of the load test. Ddosify supports 3 load types. | string | linear | No |
--config | Configuration file of the load test. | string | - | No |
--version | Prints version, git commit, built date (utc), go information and quit | - | - | No |
--cert_path | A path to a certificate file (usually called 'cert.pem') | - | - | No |
--cert_key_path | A path to a certificate key file (usually called 'key.pem') | - | - | No |
--debug | Iterates the scenario once and prints curl-like verbose result. Note that this flag overrides json config. | bool | false | No |
Configuration File
Configuration file lets you use all the capabilities of Ddosify.
The features you can use by config file:
- Scenario creation
- Environment variables
- Correlation
- Assertions
- Cookies
- Custom load type creation
- Payload from a file
- Multipart/form-data payload
- Extra connection configuration
- HTTP2 support
Usage:
ddosify -config <json_config_path>
There is an example config file at config_examples/config.json. This file contains all of the parameters you can use. Details of each parameter;
-
iteration_count
(optional)This is the equivalent of the
-n
flag. The difference is that if you have multiple steps in your scenario, this value represents the iteration count of the steps. -
load_type
(optional)This is the equivalent of the
-l
flag. -
duration
(optional)This is the equivalent of the
-d
flag. -
manual_load
(optional)If you are looking for creating your own custom load type, you can use this feature. The example below says that Ddosify will run the scenario 5 times, 10 times, and 20 times, respectively along with the provided durations.
iteration_count
andduration
will be auto-filled by Ddosify according tomanual_load
configuration. In this example,iteration_count
will be 35 and theduration
will be 18 seconds. Alsomanual_load
overridesload_type
if you provide both of them. As a result, you don't need to provide these 3 parameters when usingmanual_load
."manual_load": [
{"duration": 5, "count": 5},
{"duration": 6, "count": 10},
{"duration": 7, "count": 20}
] -
proxy
(optional)This is the equivalent of the
-P
flag. -
output
(optional)This is the equivalent of the
-o
flag. -
engine_mode
(optional)Can be one of
distinct-user
,repeated-user
, or default modeddosify
.distinct-user
mode simulates a new user for every iteration.repeated-user
mode can use pre-used user in subsequent iterations.ddosify
mode is default mode of the engine. In this mode engine runs in its max capacity, and does not show user simulation behaviour.
-
env
(optional)Scenario-scoped global variables. Note that dynamic variables changes every iteration.
"env": {
"COMPANY_NAME" :"Ddosify",
"randomCountry" : "{{_randomCountry}}"
} -
data
(optional)Config for loading test data from a CSV file. CSV data used in below config.
"data":{
"info": {
"path" : "config/config_testdata/test.csv",
"delimiter": ";",
"vars": {
"0":{"tag":"name"},
"1":{"tag":"city"},
"2":{"tag":"team"},
"3":{"tag":"payload", "type":"json"},
"4":{"tag":"age", "type":"int"}
},
"allow_quota" : true,
"order": "sequential",
"skip_first_line" : true,
"skip_empty_line" : true
}
}Field Description Type Default Required? path
Local path or remote url for your CSV file string
- Yes delimiter
Delimiter for reading CSV string
,
No vars
Tag columns using column index as key, use type
field if you want to cast a column to a specific type, default isstring
, can be one of the following:json
,int
,float
,bool
.map
- Yes allow_quota
If set to true, a quote may appear in an unquoted field and a non-doubled quote may appear in a quoted field bool
false
No order
Order of reading records from CSV. Can be random
orsequential
string
random
No skip_first_line
Skips first line while reading records from CSV. bool
false
No skip_empty_line
Skips empty lines while reading records from CSV. bool
true
No -
success_criterias
(optional)Config for pass fail logic for the test. abort and delay fields can be used to adjust the abort behaviour in case of failure. If abort is true for a rule and rules fails at certain point, engine will decide to abort test immediately if delay is 0 or not given. If delay is given, it will wait for delay seconds and reassert the rule.
Example: Check 90th percentile and fail_count;
{
"duration": 10,
<other_global_configurations>,
"success_criterias": [
{
"rule" : "p90(iteration_duration) < 220",
"abort" : false
},
{
"rule" : "fail_count_perc < 0.1",
"abort" : true,
"delay" : 1
},
{
"rule" : "fail_count < 100",
"abort" : true,
"delay" : 0
}
],
"steps": [....]
} -
steps
(required)This parameter lets you create your scenario. Ddosify runs the provided steps, respectively. For the given example file step id: 2 will be executed immediately after the response of step id: 1 is received. The order of the execution is the same as the order of the steps in the config file.
Details of each parameter for a step;
-
id
(required)Each step must have a unique integer id.
-
url
(required)This is the equivalent of the
-t
flag. -
Name of the step.
-
method
(optional)This is the equivalent of the
-m
flag. -
headers
(optional)List of headers with key:value format.
-
payload
(optional)Body or payload. This is the equivalent of the
-b
flag.Note: If you want to use
x-www-form-urlencoded
, set Content-Type header toapplication/x-www-form-urlencoded
.Example: send
x-www-form-urlencoded
data;{
"headers": {
"Content-Type": "application/x-www-form-urlencoded"
},
"payload": "key1=value1&key2=value2"
} -
payload_file
(optional)If you need a long payload, we suggest using this parameter instead of
payload
. -
Use this for
multipart/form-data
Content-Type.Accepts list of
form-field
objects, structured as below;{
"name": [field-name],
"value": [field-value|file-path|url],
"type": <text|file>, // Default "text"
"src": <local|remote> // Default "local"
}Example: Sending form name-value pairs;
"payload_multipart": [
{
"name": "[field-name]",
"value": "[field-value]"
}
]Example: Sending form name-value pairs and a local file;
"payload_multipart": [
{
"name": "[field-name]",
"value": "[field-value]",
},
{
"name": "[field-name]",
"value": "./test.png",
"type": "file"
}
]Example: Sending form name-value pairs and a local file and a remote file;
"payload_multipart": [
{
"name": "[field-name]",
"value": "[field-value]",
},
{
"name": "[field-name]",
"value": "./test.png",
"type": "file"
},
{
"name": "[field-name]",
"value": "http://getanteon.com/test.png",
"type": "file",
"src": "remote"
}
]Note: Ddosify adds
Content-Type: multipart/form-data; boundary=[generated-boundary-value]
header to the request when usingpayload_multipart
. -
timeout
(optional)This is the equivalent of the
-T
flag. -
capture_env
(optional)Config for extraction of variables to use them in next steps. Example: Capture NUM variable from steps response body;
"steps": [
{
"id": 1,
"url": "http://getanteon.com/endpoint1",
"capture_env": {
"NUM" :{"from":"body","json_path":"num"},
}
},
] -
assertion
(optional)The response from this step will be subject to the assertion rules. If one of the provided rules fails, step is considered as failure. Example: Check status code and content-length header values;
"steps": [
{
"id": 1,
"url": "http://getanteon.com/endpoint1",
"assertion": [
"equals(status_code,200)",
"in(headers.content-length,[2000,3000])"
]
},
] -
Sleep duration(ms) before executing the next step. Can be an exact duration or a range.
Example: Sleep 1000ms after step-1;
"steps": [
{
"id": 1,
"url": "http://getanteon.com/endpoint1",
"sleep": "1000"
},
{
"id": 2,
"url": "http://getanteon.com/endpoint2",
}
]Example: Sleep between 300ms-500ms after step-1;
"steps": [
{
"id": 1,
"url": "http://getanteon.com/endpoint1",
"sleep": "300-500"
},
{
"id": 2,
"url": "http://getanteon.com/endpoint2",
}
] -
auth
(optional)Basic authentication.
"auth": {
"username": "test_user",
"password": "12345"
} -
others
(optional)This parameter accepts dynamic key: value pairs to configure connection details of the protocol in use.
"others": {
"disable-compression": false, // Default true
"h2": true, // Enables HTTP/2. Default false.
"disable-redirect": true // Default false
}
-