anteon
anteon copied to clipboard
Localhost connections give "connection refused" errors
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
}
]
}
Hi @douglasg14b, are you using the Docker version of Ddosify?
Nope, the command line version.
same issue here using latest version, and it looks like ddosify doesn't honor keep-alive even if it is set in the config via "keep-alive": true, I am using the config based cli, even after increasing ulimit on my mac to 128k I still see the test starts failing after a short time, even with load of 10k request over 20s, it doesn't make sense to use that many connections to send so little qps, consider based on the code here: https://github.com/ddosify/ddosify/blob/master/core/scenario/requester/http.go#L434, the MaxIdleConnsPerHost is hardcoded as 60000
Hi @douglasg14b, I could not reproduce this issue.
I started a nginx server on my machine:
docker run -it --rm -p 8080:80 nginx
I can access it from a web browser with http://localhost:8080
Then I used Ddosify to test the nginx endpoint:
➜ ~ ddosify -version
Version: v0.13.2
Git commit: 6e3511d
Built 2023-02-06T09:51:34Z
Go version: go1.18.10
OS/Arch: darwin/arm64
➜ ~
➜ ~ ddosify -t http://localhost:8080
⚙️ Initializing...
🔥 Engine fired.
🛑 CTRL+C to gracefully stop.
✔️ Successful Run: 14 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00423s
✔️ Successful Run: 29 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00296s
^C✔️ Successful Run: 33 100% ❌ Failed Run: 0 0% ⏱️ Avg. Duration: 0.00300s
RESULT
-------------------------------------
Success Count: 33 (100%)
Failed Count: 0 (0%)
Durations (Avg):
DNS :0.0000s
Connection :0.0000s
Request Write :0.0001s
Server Processing :0.0028s
Response Read :0.0001s
Total :0.0030s
Status Code (Message) :Count
200 (OK) :33
The status code is 200
. Then I tried with your config file and changed the URL to nginx. Again, I did not get connection refused
error.
Please give me some details of your target server to reproduce this issue. Thanks.
Hi @douglasg14b, are you using the Docker version of Ddosify?
Hi @fatihbaltaci, apologies for sort of hijacking this issue. What would be the solution when using the Docker version?
Hi @zvdbit, you can add --network host
when using Ddosify in Docker. Here is an example:
docker run -it --rm --network host ddosify/ddosify ddosify -t http://localhost:8080
Ddosify can access http://localhost:8080
server.
The target server in my case is Kestrel, a C# Asp.Net Core project ran in debug mode.
Hi @zvdbit, you can add
--network host
when using Ddosify in Docker. Here is an example:docker run -it --rm --network host ddosify/ddosify ddosify -t http://localhost:8080
Ddosify can access
http://localhost:8080
server.
Thanks, the --network host
resolves the issue.
Hi @cdong8812, we released a new version of Ddosify v0.15.0. In this release:
- We removed the
keep-alive
option from the config file. You can set theConnection
header for each step. - We introduced the
engine_mode
option. You can setengine_mode
todistinct-user
in your config file if you want Ddosify to use the existing connection between steps (keep-alive) and different connections between iterations.
You can find the details in the config file section. Thanks.
FWIW, I experienced similar issues, and found that I was running out of local ports, since the default port range on linux only allows for ~28k outbound connections.
In my case, setting sysctl net.ipv4.ip_local_port_range="1024 61000"
during testing helped.