全局限速了没？
全局限速已经设置为 Unlimited 了
设置一下全局限速，看看有没有改善呢
效果好像挺不错的，我现在限制上下行都是 100KB/s，观察到 WebAPI 的响应性能显著提高。
最重要的大概是现在终于能在合理的时间范围内完成一轮检查（尽管和其它下载器仍有差距）。
另一个注意到的问题是，从这个新的版本开始，有一些请求似乎被 BitComet 给关闭了。这在之前的版本中没有发生过。
1個讚
居然是限速了下载速度，导致api请求发送给比特彗星，比特彗星因为限速下行速度，，，收不到包导致的吗！？
看来全局限速启用后对http server的数据处理吞吐量有显著影响。好在 network.ignore_remote_access_in_speed_limit 的bug找到并修复了。
非全局限速的情况下，响应延迟有5秒多，也不太正常，主线程CPU应该跑满了。你有符号文件的话，可以用VC做一下cpu profile，看看哪个函数造成的延迟。
这个比较奇怪，我没有改动其他地方的代码
是的哦
2個讚
这个限速的设置似乎默认还是在高级选项中关闭并且需要手动启用的，未来是否考虑默认启用呢？
1個讚
可以考虑
你看一下全局日志里的[SYSTEM]类别消息，里面有webui.zip的加载位置。得把exe复制到原安装位置，或者把完整安装包里的webui子目录复制到exe新位置
2個讚
那比特彗星本身界面卡顿呢。。。文件数越多就越卡是啥问题
是指运行的BT任务里的文件多，还是长效做种的文件多，还是其他什么情况？
这里的问题找到了，我这边默认查询 Peers 是 16 并发请求。虽然在 qb、deluge 和 bbt 上没问题，但是对于 BitComet 来说似乎用力过猛。
修改到 3 并发后就没有这个断开连接的问题了。
1個讚
我这里 50 个任务放开限速跑，就已经足够让 GUI 卡到点不动了。
更多的测试我会明天去做，也辛苦您这么晚还在 debug 了 
BT任务的文件多，可以全选列表里的任务，右键属性能看到整个BT软件中的文件数量
在统计分类里面观察长效做种文件是一种简单的观察文件总数办法而已，导致问题的不是长效做种，是BT任务引起的界面卡顿
软件里运行1000个文件的情况，界面响应时间大概在170ms，文件数越多越卡，不知道楼上50个任务的时候说界面卡是有多少文件数
如果1w个文件数，，基本就是界面上点一下鼠标右键，一两秒才有菜单弹出来的反映了
我只有 169 个文件哦，和文件数量应该没什么关系~
晚上好，我今天抽空对 BitComet 任务一跑起来就特别卡的问题跑了一下 CPU Profile
然后很诡异的发现，不知道什么原因，BitTorrent 的一部分操作居然跑在了窗口 UI 线程上。
主要耗时分成了两个部分
- 一个是 Core_Common:InterfaceMessage 里面的 time_tick调用的 Core_Common::MessageQueue::message_handle，耗时高达 31.63%
- 另一个是 Core_Common::InterfaceTimer::time_tick 里面对 Core_BitTorrent::BitTorrentPeerPool::optimize_peer_connections 的调用耗时占用了 10.42%，这一部分耗时主要消耗在了 peer_auto_connect → BitTorrentPeer::connect 上面
- 还有一部分是 UDP 的包处理，不过这部分因为我关了 uTP，所以看着还好
我也重点关注了一下 Core_Wire::InterfaceWire 和 Core_Common:InterfaceMessage 的情况，其中 Core_Wire::InterfaceWire 的情况还不错，没有看到很高的占用。但 Core_Common:InterfaceMessage 就不太行了。
一个可以快速复现卡住的情况是全选种子，然后更新 Tracker。此时 GUI 会直接陷入无响应的状态。在无响应刚刚结束的瞬间，我截了个图，发现有大量的 wire_handle_socket_received 和 wire_handle_socket_send_buffer_empty在排队。
其中我注意到 wire_handle_socket_send_buffer_empty 的 max 值相当高，而且 avg 也不小 avg: 37ms(32952#), max: 1218061ms, wire_handle_socket_send_buffer_empty
从热路径上看似乎优化空间不大，可能得考虑把相关任务从 UI 线程上挪出去？
看起来 BitComet 在广泛使用调度器，也许可以考虑挪出 UI 线程后，用调度器更新 UI，整个锁什么的。
编辑：我个人觉得这个 wire_handle_socket_send_buffer_empty 问题相当大。
对于要存取任务数据所以要在主线程上操作我表示理解，不过也许可以考虑把这种网络 I/O 单独挪个线程？
1個讚
说的这个ui线程其实就是主线程吧，估计不是很好改现有核心构造，不然应该早就拆分成工作线程了
我全选任务更新tracker倒是不会卡，，，如果是全选选择批量替换tracker倒是就会卡住，难道是select模型 socket，Windows还是得调度去iocp
我好像十年前就提过多线程实现方案，，，但是一直咕了，翻了下翻到前两年的帖子
还有上个版本上说的，，，把tracker最大间隔改长点？现在是2小时整数，多腾出3分钟用来差分（难道要通知tracker服务器管理员改成117分钟）
看起来从楼上贴出的数据现在是找到界面卡顿的相关函数了，，，那就尽快优化下吧
应该wx之前跑profile就看出来了，只是我觉得它确实应该单开个线程
BT下载分块数据检验、peer连接优化等操作都在这里面。网络socket、磁盘IO、DHT等是有单独线程的，但涉及任务对象的操作目前都是在界面线程（主线程）。回头有时间可以把任务数据处理线程独立出来，界面刷新改为异步调用，也不加锁了。
这几天在更新安卓版，准备把webui也加进去
2個讚