Anteon (formerly Ddosify) - Effortless Kubernetes Monitoring and Performance Testing. Available on CLI, Self-Hosted, and Cloud
Home Page: https://getanteon.com
License: GNU Affero General Public License v3.0
when load tests occur, there are failures observed. Looking for an option to log the request response so that inspection of the error can be performed for the errors that occur.
Describe the bug
Error installing the CLI script
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expected that the utility would be installed without error.
Screenshots
System (please complete the following information):
I've installed ddosify via brew and go as well but still getting not found in path
How does the json description file step refer to the interface response result returned in the previous step
The Ddosify load testing tool currently allows users to start a load test using a JSON configuration file with the -config option. More info. However, there is no functionality to inject operating system environment variables into various fields of the JSON configuration file such as body, URL, header key, header value, basic auth user, and pass.
It would be beneficial to provide support for using operating system environment variables in the config.json file using a specific format like {{$USER}}. Below is an example of how this might be implemented for the USER environment variable from the operating system:
{
"output": "stdout",
"duration": 100,
"load_type": "linear",
"iteration_count": 10,
"steps": [
{
"id": 1,
"url": "https://servdown.com",
"name": "",
"method": "GET",
"headers": {
"os-user": "{{$USER}}"
},
"timeout": 10
}
]
}Expected Behavior:
Ddosify should recognize and replace environment variable placeholders, such as {{$USER}}, with the corresponding values from the operating system. The format is: {{$ANY_OS_VARIABLE}}
This should apply to all relevant fields in the JSON configuration file, including:
If Ddosify did not find the environment variable in the operating system, it should exit with an error. Example: {{$USER}} is not found in the operating system environment variables
Current Behavior:
There is no support for injecting operating system environment variables into the JSON configuration file. It gave err: ScenarioValidationError {{$USER}} is not defined to use by global and captured environments error.
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.
Hello!
I've tried to make load tests on my services and it seems that linear type doesn't work correctly.
I think linear load test means that total requests number evenly spliited over the test duration time. For example:
request_count=100
duration=10
With this configuration 10 requests will be sent every second.
Another example:
request_count=10
duration=100
With this configuration 1 request will be sent every 10 second.
How does it work now: all requests are sent in the beginning of test and the rest of the time Ddosify does nothing. I've attach example of my configuration and the result of test where it is seen (after about 5 seconds all requests will be sent).
{
"request_count": 15,
"duration": 30,
"load_type": "linear",
"output": "stdout",
"steps": [
{
"id": 1,
"url": "https://target_site.com/endpoint1",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 2,
"url": "https://target_site.com/endpoint2",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 3,
"url": "https://target_site.com/endpoint3",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 4,
"url": "https://target_site.com/endpoint4",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 5,
"url": "https://target_site.com/endpoint5",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 6,
"url": "https://target_site.com/endpoint6",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 7,
"url": "https://target_site.com/endpoint7",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 8,
"url": "https://target_site.com/endpoint8",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 9,
"url": "https://target_site.com/endpoint9",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 10,
"url": "https://target_site.com/endpoint10",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 11,
"url": "https://target_site.com/endpoint11",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 12,
"url": "https://target_site.com/endpoint12",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 13,
"url": "https://target_site.com/endpoint13",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 14,
"url": "https://target_site.com/endpoint14",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 15,
"url": "https://target_site.com/endpoint15",
"protocol": "https",
"method": "GET",
"timeout": 5
},
{
"id": 16,
"url": "https://target_site.com/endpoint16",
"protocol": "https",
"method": "GET",
"timeout": 5
}
]
}
⚙️ Initializing...
🔥 Engine fired.
🛑 CTRL+C to gracefully stop.
✔️ Successful Run: 0 0% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00000s
✔️ Successful Run: 0 0% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00000s
✔️ Successful Run: 0 0% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00000s
✔️ Successful Run: 13 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.59933s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
✔️ Successful Run: 15 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 4.64857s
RESULT
-------------------------------------
Step 1
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0106s
Connection :0.0005s
TLS :0.0025s
Request Write :0.0001s
Server Processing :0.7596s
Response Read :0.0000s
Total :0.7733s
Status Code (Message) :Count
200 (OK) :15
Step 2
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0107s
Connection :0.0003s
TLS :0.0022s
Request Write :0.0001s
Server Processing :0.3240s
Response Read :0.0000s
Total :0.3373s
Status Code (Message) :Count
200 (OK) :15
Step 3
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0112s
Connection :0.0003s
TLS :0.0022s
Request Write :0.0001s
Server Processing :0.2309s
Response Read :0.0000s
Total :0.2447s
Status Code (Message) :Count
200 (OK) :15
Step 4
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0101s
Connection :0.0003s
TLS :0.0024s
Request Write :0.0001s
Server Processing :0.6788s
Response Read :0.0001s
Total :0.6919s
Status Code (Message) :Count
200 (OK) :15
Step 5
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0111s
Connection :0.0003s
TLS :0.0032s
Request Write :0.0001s
Server Processing :0.3239s
Response Read :0.0001s
Total :0.3388s
Status Code (Message) :Count
200 (OK) :15
Step 6
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0090s
Connection :0.0003s
TLS :0.0024s
Request Write :0.0002s
Server Processing :0.2186s
Response Read :0.0000s
Total :0.2305s
Status Code (Message) :Count
200 (OK) :15
Step 7
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0096s
Connection :0.0003s
TLS :0.0032s
Request Write :0.0001s
Server Processing :0.0966s
Response Read :0.0000s
Total :0.1098s
Status Code (Message) :Count
200 (OK) :15
Step 8
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0087s
Connection :0.0003s
TLS :0.0023s
Request Write :0.0002s
Server Processing :0.2409s
Response Read :0.0000s
Total :0.2524s
Status Code (Message) :Count
200 (OK) :15
Step 9
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0101s
Connection :0.0004s
TLS :0.0025s
Request Write :0.0001s
Server Processing :0.2421s
Response Read :0.0001s
Total :0.2553s
Status Code (Message) :Count
200 (OK) :15
Step 10
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0096s
Connection :0.0004s
TLS :0.0025s
Request Write :0.0001s
Server Processing :0.1806s
Response Read :0.0000s
Total :0.1932s
Status Code (Message) :Count
200 (OK) :15
Step 11
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0081s
Connection :0.0003s
TLS :0.0026s
Request Write :0.0001s
Server Processing :0.4037s
Response Read :0.0000s
Total :0.4148s
Status Code (Message) :Count
200 (OK) :15
Step 12
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0081s
Connection :0.0004s
TLS :0.0025s
Request Write :0.0001s
Server Processing :0.2880s
Response Read :0.0000s
Total :0.2991s
Status Code (Message) :Count
200 (OK) :15
Step 13
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0099s
Connection :0.0003s
TLS :0.0023s
Request Write :0.0001s
Server Processing :0.1818s
Response Read :0.0000s
Total :0.1944s
Status Code (Message) :Count
200 (OK) :15
Step 14
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0092s
Connection :0.0003s
TLS :0.0023s
Request Write :0.0002s
Server Processing :0.1217s
Response Read :0.0000s
Total :0.1337s
Status Code (Message) :Count
200 (OK) :15
Step 15
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0091s
Connection :0.0003s
TLS :0.0021s
Request Write :0.0001s
Server Processing :0.0878s
Response Read :0.0000s
Total :0.0993s
Status Code (Message) :Count
200 (OK) :15
Step 16
-------------------------------------
Success Count: 15 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0100s
Connection :0.0003s
TLS :0.0023s
Request Write :0.0002s
Server Processing :0.0674s
Response Read :0.0000s
Total :0.0801s
Status Code (Message) :Count
200 (OK) :15
The allow_quota option should be renamed to allow_quote - it's related to quote marks, not a quota(limit)
Our business interface has a custom signature algorithm, how do I do a custom algorithm function when I do a pressure testing interface
I think all of these could be done in a shell as well?
Using https://github.com/fdehau/tui-rs or something more simple to achieve the output just bar charts like htop.
I wonder if it's something which could be helpful.
The logs now show a generic "Go-http-client/1.1" maybe better to show ddosify for Docker with the version or something
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:
Maybe I'm using it wrong, but I thought as a docker extension this is something I can use to test my local containers
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
When testing to see how much load an API handled before breaking, it would be nice to see a requests/s count when in non-linear mode.
Is there an existing way to get this info from the CLI tool?
I'm doing some testing with your software. On a test with 1650 POSTS requests per second, where on the body of the request {{_randomString}} it's used twice, I get the following output after a few minutes:
✔️ Successful Run: 570695 99% ❌ Failed Run: 61 1% ⏱️ Avg. Duration: 0.47102s
panic: runtime error: index out of range [-1]
goroutine 4020490 [running]:
math/rand.(*rngSource).Uint64(...)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rng.go:249
math/rand.(*rngSource).Int63(0xc008ef2cf8?)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rng.go:234 +0x92
math/rand.(*Rand).Int63(...)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rand.go:84
math/rand.(*Rand).Int31(...)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rand.go:98
math/rand.(*Rand).Int31n(0xc000279110, 0x1a)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rand.go:133 +0x59
math/rand.(*Rand).Intn(0x0?, 0x0?)
/opt/hostedtoolcache/go/1.18.9/x64/src/math/rand/rand.go:171 +0x2e
github.com/ddosify/go-faker/faker.Faker.IntBetween({0x0?}, 0x61, 0x0?)
/home/runner/go/pkg/mod/github.com/ddosify/[email protected]/faker/faker.go:652 +0x57
github.com/ddosify/go-faker/faker.Faker.RandomLetter({0x1?})
/home/runner/go/pkg/mod/github.com/ddosify/[email protected]/faker/faker.go:634 +0x25
github.com/ddosify/go-faker/faker.Faker.RandomStringWithLength({0x0?}, 0xa)
/home/runner/go/pkg/mod/github.com/ddosify/[email protected]/faker/faker.go:628 +0x76
github.com/ddosify/go-faker/faker.Faker.RandomString({0x2?})
/home/runner/go/pkg/mod/github.com/ddosify/[email protected]/faker/faker.go:622 +0x1e
reflect.Value.call({0x746840?, 0xc0002d6600?, 0x1000000003002?}, {0x7b5c7d, 0x4}, {0x0, 0x0, 0x2?})
/opt/hostedtoolcache/go/1.18.9/x64/src/reflect/value.go:556 +0x845
reflect.Value.Call({0x746840?, 0xc0002d6600?, 0xc0000a9546?}, {0x0, 0x0, 0x0})
/opt/hostedtoolcache/go/1.18.9/x64/src/reflect/value.go:339 +0xbf
go.ddosify.com/ddosify/core/scenario/scripting/injection.(*EnvironmentInjector).getFakeData(0xc0000a9543?, {0xc0000a9546, 0xc})
/home/runner/work/ddosify/ddosify/core/scenario/scripting/injection/environment.go:37 +0xde
go.ddosify.com/ddosify/core/scenario/scripting/injection.(*EnvironmentInjector).InjectDynamic.func1({0xc0000a9543, 0x11})
/home/runner/work/ddosify/ddosify/core/scenario/scripting/injection/environment.go:138 +0x73
regexp.(*Regexp).ReplaceAllStringFunc.func1({0xc0095cc650, 0x3, 0x8}, {0xc0095cc640?, 0xc002a00400?, 0x0?})
/opt/hostedtoolcache/go/1.18.9/x64/src/regexp/regexp.go:602 +0x91
regexp.(*Regexp).replaceAll(0xc0002a3ea0, {0x0, 0x0, 0x0}, {0xc0000a9540, 0x34}, 0x2, 0xc008ef3750)
/opt/hostedtoolcache/go/1.18.9/x64/src/regexp/regexp.go:640 +0x3ee
regexp.(*Regexp).ReplaceAllStringFunc(0xc006f645c0?, {0xc0000a9540?, 0x40?}, 0x3?)
/opt/hostedtoolcache/go/1.18.9/x64/src/regexp/regexp.go:601 +0x5d
go.ddosify.com/ddosify/core/scenario/scripting/injection.(*EnvironmentInjector).InjectDynamic(0xc0002ba940, {0xc0000a9540, 0x34})
/home/runner/work/ddosify/ddosify/core/scenario/scripting/injection/environment.go:191 +0x157
go.ddosify.com/ddosify/core/scenario/requester.(*HttpRequester).prepareReq(0xc0000d56c0, 0x0?, 0xc0095cc5f8?)
/home/runner/work/ddosify/ddosify/core/scenario/requester/http.go:307 +0x105
go.ddosify.com/ddosify/core/scenario/requester.(*HttpRequester).Send(0xc0000d56c0, 0xc0078e6db0)
/home/runner/work/ddosify/ddosify/core/scenario/requester/http.go:191 +0x1b7
go.ddosify.com/ddosify/core/scenario.(*ScenarioService).Do(0xc0002c4ee0, 0x0, {0x0?, 0xc00034a420?, 0xbc7c00?})
/home/runner/work/ddosify/ddosify/core/scenario/service.go:119 +0x3e2
go.ddosify.com/ddosify/core.(*engine).runWorker(0xc000360000, {0x0?, 0xc00ad671a0?, 0xbc7c00?})
/home/runner/work/ddosify/ddosify/core/engine.go:159 +0xe5
go.ddosify.com/ddosify/core.(*engine).runWorkers.func1({0xc003e677d0?, 0x646806?, 0xbc7c00?})
/home/runner/work/ddosify/ddosify/core/engine.go:146 +0x33
created by go.ddosify.com/ddosify/core.(*engine).runWorkers
/home/runner/work/ddosify/ddosify/core/engine.go:145 +0x2e
Tested on debian 11.
Describe the bug
using the Web UI I can add custom headers to any request. If I try to modify the host header either using a variable or using directly a static fqdn the test is run with the host header value set to the original ip / fqdn in the request
To Reproduce
Create a new test, with just one step, a simple get and use a IP address in the url
In the step options, headers, add a host header with a name of any domain you want.
run the test in debug mode, the host header will show the IP address instead of the FQDN you set in the request.
Expected behavior
the request being sent with the value I set in the host header, whatever it is. No header should be excluded from modification.
Screenshots
System (please complete the following information):
ddosify/selfhosted_hammer 1.4.0
ddosify/selfhosted_frontend 1.1.2
ddosify/selfhosted_backend 1.3.0
ddosify/selfhosted_hammermanager 1.2.0
chrislusf/seaweedfs 3.51
influxdb 2.6.1
nginx 1.23.3-alpine
busybox 1.34.1
postgres 13.6
redis 6.2.6
rabbitmq 3.9.4
Additional context
Usage Case is as follows
In my environments all dns names are resolved to a central haproxy servers using the host header as routing criteria to different backend groups. The servers behind haproxy also validate the host header in the request before allow the request to be processed.
I am deploying a new set of servers with newer versions of the app and want to test them, but to isolate properly the servers from haproxy I need to set either the host header or create custom dns entries in the engine container.
In my case, I have a Test Plan that only has to login into a website just once, because if it does so every time the test runs, the previous Bearer Token result is invalidated, and the test may not complete successfully. It would be nice to have the possibility to add a Setup and Teardown stage, where you can configure steps to be run only once.
Thanks in advance.
Regards
Hello,
In order to better simulate a user interaction with a web page I think it would be interesting to have this middle point for keep-alive in multi-step configurations.
When a user interacts with a web page a number of URL are gathered and then the connection is closed when the user exits the web page or goes idle. So it would be nice to be able to simulate this behaviour, to keep alive the connection from the first step to the last one like a real user would do and then close it after the last step to simulate that a new different client it's connecting.
The idea is to generate a benchmarking load with the real ratio between connections / second and requests / second.
It's that possible right now? Would it be possible in the future?
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,
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.
When testing with say 30k requests over 30 seconds The following errors start happening:
Are these local to the device? If so are there recommended changes/setup that need to be performed before running these kinds of tests?
This happens on both Windows & Linux.
RESULT
-------------------------------------
Success Count: 1699 (5%)
Failed Count: 28301 (95%)
Durations (Avg):
DNS :0.0176s
Connection :0.2787s
Request Write :0.0001s
Server Processing :0.1124s
Response Read :0.0000s
Total :0.6075s
Status Code (Message) :Count
200 (OK) :1699
Error Distribution (Count:Reason):
17899 :connection timeout
2 :context deadline exceeded (Client.Timeout or context cancellation while reading body)
10400 :read timeout
I guess sometimes it may be useful.
on
and has so many options! my favorite written in go. thank you so much for this! please code more like this. ddosify doesn't consume much resources, runs smooth on my smartphone without root and installation!
is this a ddos tool?
Can I use file which contains proxies, not just one in parameters?
Need:
In some (load) scenarios multiple cookies should be captured and send (even if they contain a comma)
Spec
see https://www.rfc-editor.org/rfc/rfc7230#section-3.2.2
proposed changes:
Hey stumbled in the reddit post talking about this tool and saw more protocols are planned so putting this here as a placeholder to gauge interest for you.
Would be nice to have the same testing interface to test DNS over udp/53 and tcp/53 in dns wire format as DoH/853 with HTTP payloads.
Is there a way to import postman collection to run load tests. ?
Is there a way to set a request timeout greater than 30 seconds in the self-hosted application?
I'm testing a case where some requests take up to almost a minute and they get marked as failed.
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
Hello everybody! Thank you for a very convenient and productive project! It would be great if you add an option:
function (fake) Random input between (min, max int) int
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:10On 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
Is there also support for sitemap loadtesting? Instead of pointing to 1 specific URL, it often is convenient for full website load testing to point to the domain/sitemap.xml and let it (random) load pages from a sitemap.
Or perhaps have a fix list of multiple URL's to load test?
Any of the above possible?
It would be cool to hide the progress output for every second and display only the RESULT putout at the end
⚙️ 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.00000sRESULT
Success Count: 0 (0%)
Failed Count: 100 (100%)Durations (Avg):
Error Distribution (Count:Reason):
100 :connection refused
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?
Hello, I tried to find this in your documentation but I couldn't, but there is some way that I can use the result of a response from one step to use it in the next step by using the config file? for example
"steps": [
{
"id": 1,
"url": ".../authentication",
"protocol": "http",
"method": "POST",
"headers": {
"Content-Type": "application/json",
"Accept": "application/json"
},
"payload": "some email an pass values",
"timeout": 3,
"others": {
"keep-alive": true,
"disableCompression": false,
"h2": true,
"disable-redirect": true
}
},
{
"id": 2,
"url": "...../users",
"protocol": "http",
"method": "GET",
"headers": {
"Authorization": "Bearer {{TOKEN got from the step 1 call}}"
},
"timeout": 3,
"others": {
"keep-alive": true,
"disableCompression": false,
"h2": true,
"disable-redirect": true
}
}
]
Thanks in advance!
How to use a proxy socks4 or socks5 ?
Is there such a possibility?
Hi,
i have setup a custom domain (*.ldev) to show on my own network. This is done via resolver config on a mac os 12 device. The problem now is that ddosify doesn't try the local DNS resolver at all and directly tries to resolve the domain given via the parent DNS resolver (which is my router):
./ddosify -t https://symfony-test.ldev/lucky/number
⚙️ Initializing...
🔥 Engine fired.
🛑 CTRL+C to gracefully stop.
✔️ Successful Run: 0 0% ❌ Failed Run: 14 100% ⏱️ Avg. Duration: 0.00000s
^C✔️ Successful Run: 0 0% ❌ Failed Run: 22 100% ⏱️ Avg. Duration: 0.00000s
RESULT
-------------------------------------
Success Count: 0 (0%)
Failed Count: 22 (100%)
Durations (Avg):
Error Distribution (Count:Reason):
22 :dial tcp: lookup symfony-test.ldev on 192.168.0.1:53: no such host
I would expect that ddosify can resolve the domain like all other tools like ping can:
ping symfony-test.ldev
PING symfony-test.ldev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.068 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.151 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.125 ms
Thanks :)
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?
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.
Would you mind to add grpc support?
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.
Will be?
There is the most common open source quic implementations in Go: https://github.com/lucas-clemente/quic-go
Running from the CLI, localhost connections give a connection refused error.
{
"iteration_count": 30000,
"debug" : false,
"load_type": "linear",
"duration": 30,
"steps": [
{
"id": 1,
"url": "http://localhost:5228/api/v1/analytics/event",
"method": "POST",
"headers": {
"Content-Type": "application/json"
},
"payload": "{\"eventData\":{\"type\":\"action\",\"name\":\"ButtonClick_SendVerificationButton\",\"buttonName\":\"back\"},\"context\":{\"scope\":\"EnterMDNDialog_SendVerificationButton\",\"scopes\":[\"EnterMDNDialog\",\"SendVerificationButton\"],\"app\":{\"appName\":\"my-app\",\"appPath\":\"\/my-app\",\"version\":2},\"device\":{\"os\":\"Windows\",\"browser\":\"Firefox\"},\"identities\":{\"deviceId\":\"abcd-1234\",\"customerId\":\"abcd-1234\"},\"extra\":{\"isSubscriber\":true,\"identifiedBy\":\"asurion-id\",\"verificationType\":\"MDN\",\"componentType\":\"BUTTON\"},\"meta\":{\"isTest\":true,\"artificial\":true}}}",
"timeout": 2
}
]
}Might be because of a mistake in the config? Either way the error should probably indicate what the problem is as opposed to be unhanded.
Command: ddosify -config loadTestConfig.json
{
"iteration_count": 3000,
"debug" : false,
"load_type": "linear",
"duration": 30,
"steps": [
{
"id": 1,
"url": "[redacted]",
"method": "POST",
"payload": {
"eventData": {
"type": "action",
"name": "ButtonClick_SendVerificationButton",
"buttonName": "back"
},
"context": {
"identities": { "deviceId": "abcd-1234", "customerId": "abcd-1234" },
"meta": {
"isTest": true,
"artificial": true
}
}
},
"timeout": 2
}
]
}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"
}
]
}
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
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.