Ddosify - High-performance load testing tool

Ddosify logo
Ddosify - High-performance load testing tool

ddosify latest version  ddosify build result  golang version  go coverage  go report  ddosify license

Ddosify - High-performance load testing tool quick start

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 packages

# For Redhat based (Fedora, CentOS, RHEL, etc.)
rpm -i https://github.com/ddosify/ddosify/releases/download/v0.1.1/ddosify_amd64.rpm

# For Debian based (Ubuntu, Linux Mint, etc.)
wget https://github.com/ddosify/ddosify/releases/download/v0.1.1/ddosify_amd64.deb
dpkg -i ddosify_amd64.deb

# For Alpine
wget https://github.com/ddosify/ddosify/releases/download/v0.1.1/ddosify_amd64.apk
apk add --allow-untrusted ddosify_amd64.apk

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.

  1. Simple load test

     ddosify -t target_site.com
    

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

  2. 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.

  3. Scenario based load test

     ddosify -config config_examples/config.json
    

    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]
Flag Description Type Default Required?
-t Target website URL. Example: https://ddosify.com string - Yes
-n Total request count int 200 No
-d Test duration in seconds. int 10 No
-p Protocol 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. string HTTPS No
-m Request method. Available methods for HTTP(s) are GET, POST, PUT, DELETE, UPDATE, PATCH 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. 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. Other output types will be added. string stdout No
-l Type of the load test. Ddosify supports 3 load types. string linear No
-config Config File of the load test. string - No

Load Types

Linear

ddosify -t target_site.com -l linear

Result:

linear load

Note: If the request count is too low for the given duration, the test might be finished earlier than you expect.

Incremental

ddosify -t target_site.com -l incremental

Result:

incremental load

Waved

ddosify -t target_site.com -l waved

Result:

waved load

Config File

Config file lets you use all capabilities of Ddosify.

The features you can use by config file;

  • Scenario 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 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.

  • proxy optional

    This is the equivalent of the -P flag.

  • output optional

    This is the equivalent of the -o flag.

  • steps mandatory

    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 mandatory

      Each step must have a unique integer id.

    • url mandatory

      This is the equivalent of the -t flag.

    • protocol optional

      This is the equivalent of the -p flag.

    • method optional

      This is the equivalent of the -m flag.

    • headers optional

      List of headers with key:value format.

    • payload optional

      This is the equivalent of the -b flag.

    • payload_file optional

      If you need a long payload, we suggest using this parameter instead of payload.

    • 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": {
          "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
open /usr/local/bin
  • Right click ddosify and select Open
  • Select Open
  • Close the opened terminal

License

Licensed under the AGPLv3: https://www.gnu.org/licenses/agpl-3.0.html

Owner
Ddosify
Multi location based load testing and DDOS attack simulation.
Ddosify
Comments
  • Extension for Docker gives

    Extension for Docker gives "connection refused" error for localhost connections, v.0.1.3

    • In Docker Desktop, Windows 10 21H2, install Ddosify extension and try to connect to a server on localhost. The following result comes out with "connection refused" at the bottom for all requests.

    ⚙️ Initializing... 🔥 Engine fired.

    ✅ Successful Run: 0 0% ❌ Failed Run: 14 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 29 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 44 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 59 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 74 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 89 100% ⏱️ Avg. Duration: 0.00000s ✅ Successful Run: 0 0% ❌ Failed Run: 100 100% ⏱️ Avg. Duration: 0.00000s

    RESULT

    Success Count: 0 (0%) Failed Count: 100 (100%)

    Durations (Avg):

    Error Distribution (Count:Reason): 100 :connection refused

    • I can connect to the "address:port" from browser without a problem.
    • I tried different ports; no chance there neither.
  • Is there a way to supply randomized data

    Is there a way to supply randomized data

    Hi

    Nice tool, I'm wondering if there is a way to send randomized data that follows a certain json definition? I see you have the config file, but i'm looking to send 1000s of request with generally unique bodies?

  • Add Arch Linux installation instructions

    Add Arch Linux installation instructions

    I've added these two packages to AUR:

    https://aur.archlinux.org/packages/ddosify/ https://aur.archlinux.org/packages/ddosify-git/

    I guess it's good to mention the installation of latest tag in README, please tell me if you prefer the git version (which installs the latest commit).

  • [Feature] Add json format output in report

    [Feature] Add json format output in report

    I have seen that we use some kind of formatted string for report output. I wonder if we can use json format (add a flag for configuring or sth.) for report output. I think structure will like below [ { // Step 1 "success_count":17, "failed_count":3, "duration":{ "dns":0.0007 // etc.. }, "status_code":{ "200":17 }, "error_distribution":{ "connection_timeout":3 } }, { // Step 2 things } ]

    And also I think it's time to refactor using template as the code writted https://github.com/ddosify/ddosify/blob/master/core/report/stdout.go#L168

  • Can't use it for localhost

    Can't use it for localhost

    I recently installed Ddosify as an extension for Docker Desktop (windows) and tried it with localhost. I have a container up and running which can be accessed via port 80 and I can open it in the browser via http://localhost

    When I do a load test, every single request fails: image image

    Maybe I'm using it wrong, but I thought as a docker extension this is something I can use to test my local containers

  • Incremental type in manual_load

    Incremental type in manual_load

    Hi all,

    First of all, thank you for this useful load testing tool. since its usage is decreasing the testing time in my project. On the other hand, I have a question related to the tool usage: ¿Is it possible to launch a load test in manual mode but with the incremental or waved type?. For now, I can specify a single load test with the three variants or a manual test with a different number of requests or duration. In this way, I would plot four different kinds of graphics: (1) Linear (2) Incremental (3) Waved (as is shown in the README.md) or (4) piecewise function (every stage of the function corresponds with a line in the manual_load JSON field). What I wanted to know is if I could create a request/seconds graphic with different forms. For example, the first step is a lineal load with X request during Y seconds and the second step is a waved load with J request in K seconds. I want something just like this: "manual_load": [ {"duration": Y, "count": X, "load_type": "linear"}, {"duration": K, "count": J, "load_type": "incremental"} ],

    Thank you once again. Best regards, Daniel.

  • Is there support for mutual tls authentication?

    Is there support for mutual tls authentication?

    I can't find any options allowing ddosify to present a TLS client certificate to the server under test. Am I missing something or isn't that supported?

  • Docker extension fails with no error when selecting https and add https://example.com in host field.

    Docker extension fails with no error when selecting https and add https://example.com in host field.

    I understand that the problem here is between the keyboard and the chair, but it's not super user friendly. Better to strip https/http from the input or to give some message that it's not a valid domain.

  • Tried to login to my app but I always get :http: server gave HTTP response to HTTPS client

    Tried to login to my app but I always get :http: server gave HTTP response to HTTPS client

    here's my config

    { "request_count": 20, "load_type": "linear", "duration": 5, "manual_load": [ {"duration": 5, "count": 5}, {"duration": 6, "count": 10}, {"duration": 7, "count": 20} ], "steps": [ { "id": 1, "url": "https://localhost:56273/signin", "protocol": "https", "headers": { "Content-Type": "application/json", "Accept": "application/json" }, "method": "POST", "payload_multipart": [ { "name": "Username", "value": "admin" }, { "name": "Password", "value": "password" }, { "name": "Persist", "value": "false" }, { "name": "ReturnUrl", "value": "~/" } ], "timeout": 10 }, { "id": 2, "url": "https://.....................", "method": "GET", "timeout": 20, "sleep": "1000" } ] }

  • Allow host header to be overridden

    Allow host header to be overridden

    Problem

    We were trying to benchmark a multi-tenant application locally, so were using localhost subdomains (e.g. test1.localhost & test2.localhost) to easily test multiple domains without any extra setup. Chrome & Firefox seem to resolve these to localhost as RFC-6761 section 6.3 says may be done. Other applications like curl don't treat this specially, but the host header can be overridden (e.g. curl localhost:8081 -H test.localhost:8081). I had hoped the same could be done in ddosify, but the host header seemed to get ignored.

    For example, in one terminal I ran nc -l 8081, then in another I ran ddosify -t http://localhost:8081 -h 'Host: test.localhost:8081' -n 1 -d 1 which sent the following request to netcat

    GET / HTTP/1.1
    Host: localhost:8081
    User-Agent: DdosifyHammer
    Connection: close
    Accept-Encoding: gzip
    
    

    I was expecting

    GET / HTTP/1.1
    Host: test.localhost:8081
    User-Agent: DdosifyHammer
    Connection: close
    Accept-Encoding: gzip
    
    

    Solution

    net/http.Request has a Host field that must be set in order to override the Host header, so I checked for the Host header key to set this field instead of adding the Host header to the http.Header map where it would get ignored.

  • Homebrew install issue:

    Homebrew install issue: "Calling bottle :unneeded is deprecated"

    Hello,

    After run brew install ddosify/tap/ddosify I received this warning:

    Warning: Calling bottle :unneeded is deprecated! There is no replacement.
    
    Please report this issue to the ddosify/tap tap (not Homebrew/brew or Homebrew/core):
      /usr/local/Homebrew/Library/Taps/ddosify/homebrew-tap/Formula/ddosify.rb:10
    

    On the 10th line of the ddosify.rb:

    # typed: false
    # frozen_string_literal: true
    
    # This file was generated by GoReleaser. DO NOT EDIT.
    class Ddosify < Formula
      desc "High-performance load testing tool, written in Golang."
      homepage "https://ddosify.com"
      version "0.4.1"
      license "AGPL-3.0-only"
      bottle :unneeded # <-- this line
    
      on_macos do
        if Hardware::CPU.intel?
        # ...
    

    My system: macOS Mojave 10.14.6 Homebrew: 3.2.17

  • Dynamic variable in domain name

    Dynamic variable in domain name

    I tried a dynamic variable in URL as shown in the example in the documentation ddosify -t target_site.com/{{_randomInt}} and it works as expected.

    But if I try the dynamic varilable in the domain like following ddosify -t https://{{_randomDomainWord}}.target_site.com i get following error: err: target is not valid: https://{{_randomDomainWord}}.target_site.com

  • Pass reference of a random id throughout steps

    Pass reference of a random id throughout steps

    I want to have a simple config.

    Get a randomUUID from your function.

    Do a POST call with that randomUUID called rid1 as a step 1

    Do a GET call with same randomUUID, rid1 as a step 2.

    This is currently not supported.

    --

    TLDR: Supporting variables throughout the config scope.

  • How can the response of GraphQL inner http status codes be examined?

    How can the response of GraphQL inner http status codes be examined?

    GraphQL operations that fail still return a 200 HTTP status code even if the inner resolvers fail How can ddosify be used with GraphQL operations?

    I'd like to see ddosify fail when inner GraphQL resolvers fail. Right now there's a success for failed executions since the GraphQL response is 200 on the external response.

  • Feature request: quantile/percentile based statistics

    Feature request: quantile/percentile based statistics

    First of all, congratulations: I'm seriously considering making ddosify part of my daily stack. Here's what I see missing. When measuring latencies it is common practice to measure a certain percentile. It is also part of the SLA terminology, which this tool could help to assess. However, I didn't find a way to get a latency statistical distribution. Are you perhaps planning to add it? Cheers

  • Feature request: record / save browsing as a config.json

    Feature request: record / save browsing as a config.json

    Hi team!

    I just arrived to your application, and it looks fairly simple to use and at the same time, really powerful, so congratulations on your side! 😃👍

    I was wondering, have you thought of a way to "record" a user's navigation in the config.json format ? It would be really super useful for example, to really automate behaviours on a website.

    Another option could also be to use other existing tools and try to "transform" the data format of each tool to ddosify's own format. For example, you could start from a .har or .js file provided by Chrome (the former if you export your navigation via network, the latter if you record a session) or else use tools like Postman with its .json format.

    Best regards,

Cloud Spanner load generator to load test your application and pre-warm the database before launch

GCSB GCSB Quickstart Create a test table Load data into table Run a load test Operations Load Single table load Multiple table load Loading into inter

Nov 30, 2022
Check-load - Simple cross-platform load average check

Sensu load average check Table of Contents Overview Usage examples Configuration

Jun 16, 2022
HTTP load testing tool and library. It's over 9000!
HTTP load testing tool and library. It's over 9000!

Vegeta Vegeta is a versatile HTTP load testing tool built out of a need to drill HTTP services with a constant request rate. It can be used both as a

Jan 7, 2023
Hive-fleet: a distributed, scalable load-testing tool built in go that leverages Google Cloud Functions

hive-fleet hive-fleet is a distributed, scalable load-testing tool, built on top

Jan 27, 2022
Simple Golang Load testing app built on top of vegeta
Simple Golang Load testing app built on top of vegeta

LOVE AND WAR : Give Your App Love By Unleashing War Simple load testing app to test your http services Installation Build docker image: docker build -

Oct 26, 2021
Trade Matching / Transaction System Load Testing Solution

Load Generation System for Trade Matching Systems Operation Users select one of the following options from thew Test Management Portal: Generate a new

Feb 25, 2022
Plow is a high-performance HTTP benchmarking tool with real-time web UI and terminal displaying
Plow is a high-performance HTTP benchmarking tool with real-time web UI and terminal displaying

Plow is a HTTP(S) benchmarking tool, written in Golang. It uses excellent fasthttp instead of Go's default net/http due to its lightning fast performance.

Jan 9, 2023
siusiu (suite-suite harmonics) a suite used to manage the suite, designed to free penetration testing engineers from learning and using various security tools, reducing the time and effort spent by penetration testing engineers on installing tools, remembering how to use tools.
siusiu (suite-suite harmonics) a suite used to manage the suite, designed to free penetration testing engineers from learning and using various security tools, reducing the time and effort spent by penetration testing engineers on installing tools, remembering how to use tools.

siusiu (suite-suite harmonics) a suite used to manage the suite, designed to free penetration testing engineers from learning and using various security tools, reducing the time and effort spent by penetration testing engineers on installing tools, remembering how to use tools.

Dec 12, 2022
A yaml data-driven testing format together with golang testing library

Specimen Yaml-based data-driven testing Specimen is a yaml data format for data-driven testing. This enforces separation between feature being tested

Nov 24, 2022
Framework of performance testing

Framework of performance testing fperf is a powerful and flexible framework which allows you to develop your own benchmark tools so much easy. You cre

Nov 30, 2022
A lightweight load balancer used to create big Selenium clusters
A lightweight load balancer used to create big Selenium clusters

Go Grid Router Go Grid Router (aka Ggr) is a lightweight active load balancer used to create scalable and highly-available Selenium clusters. Articles

Dec 28, 2022
HTTP load generator, ApacheBench (ab) replacement, formerly known as rakyll/boom
HTTP load generator, ApacheBench (ab) replacement, formerly known as rakyll/boom

hey is a tiny program that sends some load to a web application. hey was originally called boom and was influenced from Tarek Ziade's tool at tarekzia

Dec 31, 2022
Load generator for measuring overhead generated by EDRs and other logging tools on Linux

Simple load generator for stress-testing EDR software The purpose of this tool is to measure CPU overhead incurred by having active or passive securit

Nov 9, 2022
A next-generation testing tool. Orion provides a powerful DSL to write and automate your acceptance tests

Orion is born to change the way we implement our acceptance tests. It takes advantage of HCL from Hashicorp t o provide a simple DSL to write the acceptance tests.

Aug 31, 2022
Stress testing and benchmarking tool for the NEAR EVM

evm-bully --- stress testing and benchmarking tool for the NEAR EVM

May 30, 2022
Coverage testing tool for The Go Programming Language

gocov Coverage reporting tool for The Go Programming Language Installation go get github.com/axw/gocov/gocov Usage There are currently four gocov comm

Jan 3, 2023
Merge Mock - testing tool for the Ethereum Merge

MergeMock Experimental debug tooling, mocking the execution engine and consensus node for testing. work in progress Quick Start To get started, build

Oct 21, 2022
Ditto is a CLI testing tool that helps you verify if multiple HTTP endpoints have the same outputs.

Ditto is a CLI testing tool that helps you verify if multiple HTTP endpoints have the same outputs.

Nov 24, 2021
Client tool for testing HTTP server timeouts

HTTP timeout test client While testing Go HTTP server timeouts I wrote this little tool to help me test. It allows for slowing down header write and b

Sep 21, 2022