Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add disclaimer about bandwidth usage of speedtest feature #253

Closed
Colonial-Dev opened this issue Aug 6, 2022 · 3 comments
Closed

Comments

@Colonial-Dev
Copy link

Colonial-Dev commented Aug 6, 2022

Description of the feature

Dashdot's speedtest feature seems to consume dozens or even hundreds of gigabytes of bandwidth per day on default settings if you park it on a data center pipe. I'm not sure where the best place to put it would be, but inserting some sort of disclaimer into the docs for those on capped connections might be a good idea.

Additional context

I only started using dashdot a week or two ago on my Vultr VPS. Yesterday I noticed that I had already burned through six hundred gigabytes of my two terabyte monthly bandwidth allowance; inspection of the usage graphs revealed consistent hourly spikes (pretty big ones) in vCPU usage and network utilization.

At first I thought I had been pwned, but I spun down my entire Docker stack and the problem went away. I flipped them back on one at a time, and when I reached dashdot, there was a near-instant spike. I checked the logs, saw Speed-test completed successfully [ookla] and connected the dots almost immediately.

I ended up setting DASHDOT_SPEED_TEST_INTERVAL=43800 (1 month) in my docker-compose file, but I can easily see this sort of thing slipping under other people's noses and causing overage charges - hence the request.

image
Pictured: my bandwidth allowance taking a fat L. You can see the gap on the right where dashdot was stopped for ~2h, then two consecutive spikes where I started it, realized the issue, and reconstructed it with the modified interval.

Edit: confirmed, it's been 18h with no spikes.

@MauriceNino
Copy link
Owner

Thank you for creating the issue, and I am terribly sorry that this happened!
I think the best solution to prevent this in the future is to cut down the amount of times the speedtest runs to maybe every 4 hours - what do you think?

Also, where in the docs would you have expected to be a warning? I definitely agree that there should be one, but I have a hard time deciding where to put it.

@Colonial-Dev
Copy link
Author

Colonial-Dev commented Aug 7, 2022

and I am terribly sorry that this happened!

Don't worry about it! Your code did exactly what it was told, it's mainly my fault for not thinking about the implications of what I was doing 😅

As for the test interval, I think 4 hours sounds like a sane default - it tracks how your speed is impacted throughout the day (e.g. peak hours in the evening can result in throttling on residential ISPs) without being too overzealous.

I think here in the info box (or perhaps a separate warning box?) would be a good place to put it. Something along the lines of:

Warning!

Dashdot's speed testing feature can consume significant amounts of bandwidth - on the order of dozens or even hundreds of gigabytes daily if you are on a data center connection, which can pose problems if your usage is metered (say, by a VPS provider.)

Setting the environment variable DASHDOT_SPEED_TEST_INTERVAL so that tests are only run weekly or monthly can mitigate this concern.

MauriceNino added a commit that referenced this issue Aug 8, 2022
## [4.3.8](v4.3.7...v4.3.8) (2022-08-08)

### Bug Fixes

* **api:** add nfs4 to ignored network drives ([b823aab](b823aab)), closes [#252](#252)
* **api:** change speedtest interval to every 4 hrs ([a04e1f9](a04e1f9)), closes [#253](#253)
@MauriceNino
Copy link
Owner

🎉 This issue has been resolved in version 4.3.8

Please check the changelog for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants