[Potential Bug] Speedtests run with this container are significantly lower than the ones run with native CLI

[zallaevan]

Pre-work

• I have read the docs.
• I have searched open and closed issues.
• I agree to follow this project's Code of Conduct.

Description

As the title says, the upload speed is only a fraction of what is stated by the ISP and compared to the official Speedtest.net CLI tool from the very same machine. Ethernet cables are new, untwisted, and the connection is almost airtight. Other devices on the same LAN experience similar speeds via Ethernet. Quite puzzling, because I remember that maybe a year ago, this problem wasn't there at all.

Expected Behavior

Same speed on speedtest.net CLI and on this docker container.

Steps to Reproduce

1. • Set up docker compose with recurrent testing (in my case hourly) with crontab.
2. • Watch how there is a difference in upload speed on the app compared to native speedtest.net CLI.

Deployment Environment

Docker Compose

Application Information

{"environment":{"application_name":"speedtest.zz","laravel_version":"11.43.2","php_version":"8.3.17","composer_version":"2.8.5","environment":"production","debug_mode":false,"url":"speedtest.zz","maintenance_mode":false,"timezone":"Europe\/Gibraltar","locale":"en"},"cache":{"config":true,"events":true,"routes":true,"views":true},"drivers":{"broadcasting":"null","cache":"database","database":"sqlite","logs":"stderr","mail":"log","queue":"database","session":"database"},"filament":{"version":"v3.2.142","packages":"filament, forms, notifications, support, tables","views":"NOT PUBLISHED","blade_icons":"CACHED","panel_components":"CACHED"},"livewire":{"livewire":"v3.5.12"},"speedtest_tracker":{"version":"v1.2.5"}}

What browser(s) are you seeing the problem on?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

Logs

N/A

[svenvg93]

We’re using the same official Speedtest.net CLI to run the tests. In that sense, the testing is performed in exactly the same way as when you run the CLI yourself.

We’ve also seen that tests running at the top of the hour can be slower, likely due to increased congestion on the ISP network or on the Speedtest servers at that time. Do you see the same results when running a manual test in the app?

What results do you get when running docker exec -it speedtest-tracker speedtest?

[invider42]

Same for me, the manual ones are highlight on the screenshot.
The docker container run on unraid.

[svenvg93]

@invider42 Based on your screenshot it seems your running the old Speedtest Tracker, not our version 😉 .
As mentioned we’ve seen that tests running at the top of the hour can be slower, likely due to increased congestion on the ISP network or on the Speedtest servers at that time. Its also listed in the docs https://docs.speedtest-tracker.dev/help/faqs#speedtest

--

In general, we simply execute the Ookla CLI that is installed inside the Docker image. The application itself has no influence on the results. The results can only be affected by the network and/or system performance of the host running the container, or by the ISP and/or the Speedtest server being used.

The process of the application is documented here https://docs.speedtest-tracker.dev/other/speedtest-process

[alexjustesen]

@invider42 also heads up that is the old Speedtest Tracker so we don't provide support for that.

@zallaevan make sure to update your instance, you're a few versions behind and then test again.

Edit: converting to a discussion. We've seen this issue several times over the years and it turns out to either be networking related or congestion related. If it's determined that there is indeed an issue with the application we can promote it back to an issue.

[zallaevan]

@alexjustesen updated the image, changed the cron job time to another one to evade the congestion, and it seems it is working as intended so far. I will let the container run for 1 day just to make sure, but I think everything is good to go.
Maybe adding a disclaimer or a recommendation would be useful for similar selhosters like me?
Also, I'd like to know the reason why ntfy and all the other old notification channels are becoming obsolete and deprecated, just for curiosity's sake.

Thank you for your help and your awesome work. Keep it up!

[alexjustesen]

Also, I'd like to know the reason why ntfy and all the other old notification channels are becoming obsolete and deprecated, just for curiosity's sake.

I've mentioned this a few times before but essentially using Apprise let @svenvg93 and I focus on features instead of maintaining X number of notification channels. Essentially helping us cut down on maintenance/feature requests.

[zallaevan]

Oh, okay, did not find anywhere on the docs (faq, changelog, etc.) that mentioned the reason for the deprecation. I don't want to be the one asking the same question and you replying ad nauseam. Good to know.

[svenvg93]

So far we not been to vocal about it. As the removal date is not set in stone (yet) and we hope that most will migrate themself to Apprise before we remove the other channel. In the next release there will be a warning for the user when using one of the deprecated channels to make it more known. Maybe I will add a little link to the docs with the explanation why 😅 .