下载速度问题

[noxplus]

赞一下这个工具, 很不错, 就是速度有点慢.
我这边8M网络, 浏览器直接下载百度云里的文件, 速度接近1M. 但是用这个工具syncdown的时候, 10几分钟才下同步了不到10M.
手动试了下, 在__downtrunks函数里, 如果不加上Range参数, 直接header = '' ,可以观察到网卡上流量近乎1M, 但后面大小验证没通过, 文件也没能写到磁盘上.
是不是可以在这里做下优化, 分情况, 并不一定总要带上range参数?

[houtianze]

谢谢建议，看你说的数据，速度改进很明显。
不过没搞懂，Range是用来实现分段下载的，如果拿掉，怎样才可以实现分段下载？用哪个header=？怎么用？

[noxplus]

感觉也很可能是来回交互的时间占据太多时间。后来用curl试了下，速度有个明显的攀升过程，可能默认的1M分片太小，时间都耗费在交互上。不过我改成1G，一直没开始下载，也不清楚是不是其他问题。
我不怎么懂python，这里的分段是为了方便测量下载速率？ 可不可以这样，发送一次请求，程序一直接收数据，收缓冲满了后输出一次。
另外，range只输入开始位置，结束位置为空，也可以支持断点续传。

[houtianze]

之前就是发送一次请求，程序一直接收。但几个人都反应过速度不稳定，刚开始还行，但到后来就几乎卡住，特别是网络不稳定的时候。后来就改成了这种分片下载的方式，应该是解决了会卡住的问题，不过这个下载速度似乎一直不怎么理想。如果怀疑是因为下载分片太小所至，你可以通过--chunk
参数增大一下分片大小（比如 --chunk 100M），当然，前提是你的linux
box有足够的内存，看看速度会不会有很大的改进。现在程序只有接收玩完整的一个分片，才会写文件，否则一直存在内存里。这就应该是你看不到文件变大的原因。不过你可以通过看网卡状态来看看速度是不是提高很多。

2014-07-07 22:21 GMT+08:00 noxplus notifications@github.com:

感觉也很可能是来回交互的时间占据太多时间。后来用curl试了下，速度有个明显的攀升过程，可能默认的1M分片太小，时间都耗费在交互上。不过我改成1G，一直没开始下载，也不清楚是不是其他问题。
我不怎么懂python，这里的分段是为了方便测量下载速率？ 可不可以这样，发送一次请求，程序一直接收数据，收缓冲满了后输出一次。
另外，range只输入开始位置，结束位置为空，也可以支持断点续传。

—
Reply to this email directly or view it on GitHub
#61 (comment).

[noxplus]

--chunk参数对速率几乎没什么提升, 看起来是几k ~ 几十k的样子
修改headers='', 会报错
[09:56:58] Waiting 10 seconds before retrying...
然后就是不停的重试.这期间, 用ifconfig看网卡的RX, 接近满速率1M/s.
试试只在下载文件这里调用wget/curl? 我把 -d -v的输出手动拼接成一串url, wget/curl也接近1M.

[houtianze]

听起来快不少。用wget/curl时用Range header了吗？

2014-07-08 10:05 GMT+08:00 noxplus notifications@github.com:

--chunk参数对速率几乎没什么提升, 看起来是几k ~ 几十k的样子
修改headers='', 会报错
[09:56:58] Waiting 10 seconds before retrying...
然后就是不停的重试.这期间, 用ifconfig看网卡的RX, 接近满速率1M/s.
试试只在下载文件这里调用wget/curl? 我把 -d -v的输出手动拼接成一串url, wget/curl也接近1M.

—
Reply to this email directly or view it on GitHub
#61 (comment).

[noxplus]

前一个回复里提到的速率是在树莓派上用curl/wget测试的, 没加range hander.
电脑上加不加range header, 速率都在150+(网络限速了),
bypy是80k.​​
​
看来问题似乎和这个参数无关, 瓶颈在是写文件上?
我之前手动修改headers='' 导致不写文件,所以速度快.

[houtianze]

写文件应该不会是瓶颈，很简单的一个文件写入。。
只是下载有这个问题，还是上传下载都一样很慢？考虑用curl来做网络传输，不过改起来需要一段时间改代码。

2014-07-08 16:07 GMT+08:00 noxplus notifications@github.com:

前一个回复里提到的速率是在树莓派上用curl/wget测试的, 没加range hander.
电脑上加不加range header, 速率都在150+(网络限速了),
bypy是80k.​​
​
​
​

看来问题似乎和这个参数无关, 瓶颈在是写文件上?

—
Reply to this email directly or view it on GitHub
#61 (comment).

[noxplus]

电脑工具上传大致50k/s, 百度云web界面大致200k/s. 也比较慢

确认下, 是不是这个流程:
​​
​
​发送请求, 接受反馈, 收满1M数据, 写入文件, 发送请求...​...
​​

​如果是这个流程, 可以优化下, 不过具体怎么优化还得考虑...​
​​
​====分割线====
受这个项目启发, 既然针对树莓派, 考虑下做成web的. 比命令行方便太多.​​

[houtianze]

嗯，大概流程就是这样，其中包含网络传输出错的重试逻辑。

[houtianze]

我现在有点怀疑我的代码里面是不是有资源泄露，导致网络传输受阻。。

[killbus]

真的很好用哦，感谢houtianze！不过我可以贴一些日志吗？我也不懂。只是在syncup -v 的过程中，发现时不时会断掉？我不懂代码... 不知道有没有帮助。

Error accessing 'https://c.pcs.baidu.com/rest/2.0/pcs/file' Traceback (most recent call last): File "/root/Studio/python/bypy/bypy.py", line 958, in __request_work params = parsnew, timeout = self.__timeout, verify = False, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 88, in post return request('post', url, data=data, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 44, in request return session.request(method=method, url=url, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 456, in request resp = self.send(prep, *_send_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 559, in send r = adapter.send(request, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 382, in send raise SSLError(e, request=request) SSLError: The write operation timed out [17:26:45] Function: __upload_slice_act [17:26:45] Website parameters: {u'type': u'tmpfile', u'method': u'upload'} [17:26:45] Waiting 10 seconds before retrying... [17:26:55] Request Try #2 / 5 [17:34:28] Error accessing 'https://c.pcs.baidu.com/rest/2.0/pcs/file' Traceback (most recent call last): File "/root/Studio/python/bypy/bypy.py", line 958, in __request_work params = parsnew, timeout = self.__timeout, verify = False, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 88, in post return request('post', url, data=data, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 44, in request return session.request(method=method, url=url, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 456, in request resp = self.send(prep, *_send_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 559, in send r = adapter.send(request, *_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 382, in send raise SSLError(e, request=request) SSLError: The write operation timed out [17:34:28] Function: __upload_slice_act [17:34:28] Website parameters: {u'type': u'tmpfile', u'method': u'upload'} [17:34:28] Waiting 20 seconds before retrying... [17:34:48] Request Try #3 / 5 [17:36:07]

[houtianze]

网络超时，应该是网络不太稳定。如果没有中途断掉，影响不是很大。

[seanlis]

抓包看了一下
在__downchunks()里调用__get()时，如果用headers=''，GET请求的header部分

Host: nj.baidupcs.com\r\n
Accept-Encoding: identity\r\n

估计可能是由于错误的参数导致requests产生了这样的header。
如果按原来的代码headers = headers

Host: nj.baidupcs.com\r\n
Range: bytes=0-\r\n
Accept-Encoding: gzip, deflate\r\n
Accept: */*\r\n
User-Agent: python-requests/2.3.0 CPython/2.7.3 Linux/3.2.0-65-generic\r\n

根据这个试了几个header组合，发现把User-Agent去掉后，速度就上来了，原因不明。

另外，下载时Range每次只有1M，比较影响效率。我觉得应该在requests.get()时使用stream=True参数，Range只用来续传或多线程下载

[houtianze]

厉害，这个拖了N久未能解决的下载慢的问题被你找到原因了，谢。

[houtianze]

考虑把1M改成10M。以前是用stream=True来做的，不过有人反映似乎下载大文件的时候网络不稳定的时候会卡住，后来就改成现在的下载方式了。不知道你有没有什么更好的解决方案？

[seanlis]

#8
之前是这个issue提到的问题吗？

[houtianze]

嗯，应该是这个。

On Wed, Jul 16, 2014 at 6:25 PM, seanlis notifications@github.com wrote:

#8 #8
之前是这个issue提到的问题吗？

—
Reply to this email directly or view it on GitHub
#61 (comment).

[seanlis]

https://github.com/kennethreitz/requests/pull/1935
这个补丁增加了iter_content的超时，已经在2.3里面了。抛requests.exceptions.Timeout异常。

[houtianze]

佩服你的调试出错能力，原来还真是request库的问题啊。。
不过这个问题还是有点麻烦，这个改动不是向后兼容的，而且很新，很多旧一些的发行版还是没办法受惠。我看了一下我的树莓派，requests还是2.0.0。所以除了把request库加到源码库里，好像没有什么完全一点的解决方案。不过这样做的话，有点丑陋。。

[seanlis]

其实这主要是google知道的多:-)
是有点麻烦，或者对于老版本的requests时，用signal设置超时？

[houtianze]

超时会有socket signal？不过拦到了signal，要重试request好像也不简单。。都有点后悔用requests了，Python内置的那个httplib还是urllib估计比requests还是健壮一点。

[seanlis]

https://docs.python.org/2/library/signal.html#example
不过也不是很完美的办法

[houtianze]

貌似最好的方案还是直接拉最新的requests到源码库里面然后用回旧的下载函数。不过暂时还是算了，现在下载默认是20M一块，应该速度影响不会太大，稳定就好：）

[digglife]

速度高到 return haha 了我会说吗！？

[houtianze]

最新版？贴个log看看？

[houtianze]

Hi,

Thanks.
Proxy should be supported (the function is actually backed by Python),
you just set the HTTP_PROXY / HTTPS_PROXY environment variables (can google
it) accordingly. HOWEVER, it seems that it works with certain proxy, and
I'm not sure about the reason..

On Fri, Aug 15, 2014 at 11:31 AM, woomg notifications@github.com wrote:

Thanks for very useful tool!!!!
Is this support the proxy connection? If I want to connect via proxy, how
can I config this?

—
Reply to this email directly or view it on GitHub
#61 (comment).

[sunzhaoyang]

请问下载速度的问题找到了么？从百度云网页下载速度能到1M，bypy只能25k，而且重试很多，实在很崩溃。。。

[houtianze]

@sunzhaoyang 最新版也这样？这个是挺让人崩溃的，现在还不知道整洁在哪里。。。

只是下载慢，上传速度还可以？

[sunzhaoyang]

现在申请不到接口了，本来想学着写一个。不知道百度的接口返回的是一个下载的url还是别的？有没有可能用aria2c 来做下载和断点续传？现在用百度网盘的chrome插件可以直接添加到aria2c rpc，下载速度很快，唯一的弊端就是链接会1小时后失效，但重新添加也可以断点续传很方便。

[sunzhaoyang]

没试过上传，我这边基本就是拿来下电影

[houtianze]

哦。

我用的是PCS API的接口，下载就是一个简单的HTTP GET请求（需要授权后获得的access token）
http://developer.baidu.com/wiki/index.php?title=docs/pcs/rest/file_data_apis_list#.E4.B8.8B.E8.BD.BD.E5.8D.95.E4.B8.AA.E6.96.87.E4.BB.B6

这个链接也是很好构造，你下载时加上-dv参数就应该可以看到请求的url。你可以试试把这个url放入aria2c，看看速度改善是否明显。如果不明显那我推测那个chrome插件用的接口不一样。不过这个插件听起来有点意思，因为是html/js的，可以分析一下，说不定能用来改善下载。

[houtianze]

@sunzhaoyang ，你说的那个Chrome插件能给个链接吗？

[sunzhaoyang]

就是这个项目https://github.com/acgotaku/BaiduExporter
chrome插件 https://chrome.google.com/webstore/detail/baiduexporter/mjaenbjdjmgolhoafkohbhhbaiedbkno

[houtianze]

@sunzhaoyang ，感谢，我看看能挖出点东西不。

[houtianze]

服务器的顺序已更换（GAE的最后一个试）：

ac103ae

[houtianze]

看了一下，是用百度直接的请求方式（好像是BDUSS cookie验证的），一时半会儿没法直接用过来。。、

速度这个问题我猜应该是百度那面对PCS API做了限制吧。

[sunzhaoyang]

恩，应该就是pcs接口限速了。

[mckelvin]

DUP: #170

我遇到类似的问题（上传太慢），应该是pcs的限制。有2个可以做的优化:

1. 特性请求：指定PCS节点 #127 提到的换个CDN节点，当前 bypy 还没原生支持这个feature, 我的做法是找到最快的，然后改hosts.
2. 减小chunk size, 对应参数 --slice(上传) 和 --chunk(下载)，在我的测试环境里， --slice 5MB 都很慢，只能 --slice 2MB 或者更小。

  -s SLICE, --slice SLICE
                        size of file upload slice (can use '1024', '2k',
                        '3MB', etc) [default: 20 MB]
  --chunk CHUNK         size of file download chunk (can use '1024', '2k',
                        '3MB', etc) [default: 20 MB]

[malsony]

我是年付会员，百度云管家能“加速”到差不多跑满我这边的带宽，但是bypy还是100k不到。

[houtianze]

我先把这个issue关了。

下载上传速度低暂时bypy也没什么改动能有明显改进。最新版要求要requests 2.10以上，不知道会不会有帮助pip install -U bypy