Ddosify is a High-performance load testing tool

Features

  •  Protocol Agnostic – Currently supporting HTTP, HTTPS, HTTP/2. Other protocols are on the way.
  •  Scenario-Based – Create your flow in a JSON file. Without a line of code!
  •  Different Load Types – Test your system’s limits across different load types.

Installation

ddosify is available via Docker, Homebrew Tap, and downloadable pre-compiled binaries from the releases page for macOS, Linux and Windows.

Docker

docker run -it –rm ddosify/ddosify

Homebrew Tap (macOS and Linux)

brew install ddosify/tap/ddosify

apk, deb, rpm, Arch Linux packages

  • For arm architectures change ddosify_amd64 to ddosify_arm64 or ddosify_armv6.
  • Superuser privilege is required.

For Redhat based (Fedora, CentOS, RHEL, etc.)
rpm -i https://github.com/ddosify/ddosify/releases/latest/download/ddosify_amd64.rpm
For Debian based (Ubuntu, Linux Mint, etc.)
wget https://github.com/ddosify/ddosify/releases/latest/download/ddosify_amd64.deb
dpkg -i ddosify_amd64.deb
For Alpine
wget https://github.com/ddosify/ddosify/releases/latest/download/ddosify_amd64.apk
apk add –allow-untrusted ddosify_amd64.apk
For Arch Linux
git clone https://aur.archlinux.org/ddosify.git
cd ddosify
makepkg -sri

Using the convenience script (macOS and Linux)

  • The script requires root or sudo privileges to move ddosify binary to /usr/local/bin.
  • The script attempts to detect your operating system (macOS or Linux) and architecture (arm64, x86, amd64) to download the appropriate binary from the releases page.
  • By default, the script installs the latest version of ddosify.
  • If you have problems, check common issues
  • Required packages: curl and sudo

curl -sSfL https://raw.githubusercontent.com/ddosify/ddosify/master/scripts/install.sh | sh

Go install from source (macOS, Linux, Windows)

go install -v go.ddosify.com/ddosify@latest

Easy Start

This section aims to show you how to use Ddosify without deep dive into its details easily.

  • Simple load test

ddosify -t target_site.com

The above command runs a load test with the default value that is 100 requests in 10 seconds.

Using some of the features

ddosify -t target_site.com -n 1000 -d 20 -p HTTPS -m PUT -T 7 -P http://proxy_server.com:80

Ddosify sends a total of 1000 PUT requests to https://target_site.com over proxy http://proxy_server.com:80 in 20 seconds with a timeout of 7 seconds per request.

Scenario based load test

ddosify -config config_examples/config.json

  1. Ddosify first sends HTTP/2 POST request to https://test_site1.com/endpoint_1 using basic auth credentials test_user:12345 over proxy http://proxy_host.com:proxy_port and with a timeout of 3 seconds. Once the response is received, HTTPS GET request will be sent to https://test_site1.com/endpoint_2 along with the payload included in config_examples/payload.txt file with a timeout of 2 seconds. This flow will be repeated 20 times in 5 seconds and response will be written to stdout.

Details

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]

FlagDescriptionTypeDefaultRequired?
-tTarget website URL. Example: https://ddosify.comstringYes
-nTotal request countint100No
-dTest duration in seconds.int10No
-pProtocol of the request. Supported protocols are HTTP, HTTPS. HTTP/2 support is only available by using a config file as described. More protocols will be added.stringHTTPSNo
-mRequest method. Available methods for HTTP(s) are GET, POST, PUT, DELETE, UPDATE, PATCHstringGETNo
-bThe payload of the network packet. AKA body for the HTTP.stringNo
-aBasic authentication. Usage: -a username:passwordstringNo
-hHeaders of the request. You can provide multiple headers with multiple -h flag.stringNo
-TTimeout of the request in seconds.int5No
-PProxy address as host:port. -P http://user:pass@proxy_host.com:port'stringNo
-oTest result output destination. Other output types will be added.stringstdoutNo
-lType of the load test. Ddosify supports 3 load types.stringlinearNo
-configConfig File of the load test.stringNo
-versionPrints version, git commit, built date (utc), go information and quitNo

Load Types

Linear

ddosify -t target_site.com -l linear

Result:

Waved

ddosifyt target_site.com -l waved

Result:

Config File

Config file lets you use all capabilities of Ddosify.

The features you can use by config file;

  • Scenario creation
  • Custom load type creation
  • Payload from a file
  • Extra connection configuration, like keep-alive enable/disable logic
  • HTTP2 support

Usage;

ddosify -config

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;

  • request_count optionalThis 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 optionalThis is the equivalent of the -l flag.
  • duration optionalThis is the equivalent of the -d flag.
  • manual_load optionalIf 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. request_count and duration will be auto-filled by Ddosify according to manual_load configuration. In this example, request_count will be 35 and the duration will be 18 seconds. Also manual_load overrides load_type if you provide both of them. As a result, you don’t need to provide these 3 parameters when using manual_load.

“manual_load”: [
{“duration”: 5, “count”: 5},
{“duration”: 6, “count”: 10},
{“duration”: 7, “count”: 20}
]

  • proxy optionalThis is the equivalent of the -P flag.
  • output optionalThis is the equivalent of the -o flag.
  • steps mandatoryThis 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 mandatoryEach step must have a unique integer id.
    • url mandatoryThis is the equivalent of the -t flag.
    • protocol optionalThis is the equivalent of the -p flag.
    • method optionalThis is the equivalent of the -m flag.
    • headers optionalList of headers with key:value format.
    • payload optionalThis is the equivalent of the -b flag.
    • payload_file optionalIf you need a long payload, we suggest using this parameter instead of payload.
    • auth optionalBasic 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”: {
“keep-alive”: true, // Default false
“disable-compression”: false, // Default true
“h2”: true, // Enables HTTP/2. Default false.
“disable-redirect”: true // Default false
}

Common Issues

macOS Security Issue

“ddosify” can’t be opened because Apple cannot check it for malicious software.

  • Open /usr/local/bin
  • Right click ddosify and select Open
  • Select Open
  • Close the opened terminal