-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
下载测速是否应当使用多线程? #361
Comments
一般来说,单线程更能反映实际使用环境(及一般情况下大部分人都是单线程),而多线程更能反映最高速度。 不过该功能,我不是很感兴趣(用不上)。。。 |
我和楼上作者的想法其实是一样的 一个最简单的例子,你多线程测出来的IP跑满了你的带宽,假设你的带宽是100Mbps 我宁愿一个东西测出来代表的是最差情况,而不是最好的情况,因为理想情况基本上是达不到的 |
希望可以多线程同时测多个IP地址,单个IP地址还是单线程 |
功能需求
对于多线程测速,可能需要用到的人比较少。可以先摆烂。。。遇到个感兴趣的大佬可以pr合并后发版
通过head获取文件大小,例子,先探测 -url 参数的下载地址是否支持多线程
可得知206状态响应,并且响应文件大小 Content-Range: bytes 0-0/17884993
此时可多线程测速,暴力多线程就是同时执行多条汇聚测速结果,不考虑对方网站消耗流量,测速一次可能超出文件大小几倍流量
优雅点就是分割文件,例如默认四线程的情况,就砍4刀。判断17884993大于等于10M,每个线程启用2MB
此时多线程的四个请求分别为
合并文件,无需考虑,因为测速的话这些肯定不会写硬盘,也应该直接在内存中丢弃
预期目标
下载测速是否应当使用多线程?以便得到最佳的测速结果,,,因为用途是用cf来反代去下载网盘文件,都是多线程的,测速结果和实际网盘下载时候的速度结果不一致。
The text was updated successfully, but these errors were encountered: