开启debug模式后，你可以在Statistics页面查看一下 Core_Common::InterfaceMessage 分组里的消息处理函数耗时统计，有可能是个别消息处理时间过长，导致界面卡顿。
另外还可以看一下 Core_Wire::InterfaceWire 组里的信息，有可能发送缓冲区排队数据太多，造成远程访问的数据包没有及时发送出去
刚刚为了测试，关闭了 DHT 网络功能，并停止所有任务。在点击了一下停止按钮后，BitComet 崩溃了。
BitComet 崩溃后，CrashReporter 崩溃报告器来收集崩溃日志，但是崩溃报告器好像也崩溃了……
内测版代码有很多assert会直接触发主动崩溃，beta版及正式版会进行错误处理不会崩溃。
1個讚
类似sigpipe吧，一些程序的调试版本会主动崩。。。
日志好像坏掉了，现在进行请求，BitComet 不再打印任何日志了。
Enable modules 和 Filter 的 Remote Access 都打勾了，我这边程序看也有请求返回，但是就是不打印任何日志了……
我的键盘没有 ScrLock，并且过滤器选择其它模块能正常看到日志
那就不知道是什么原因了
重启了一下 BitComet，现在有正常看到日志了，可能是某种奇妙的 BUG 之类的。
这个内部调试版本还从没用过，感觉可以顺便看看utp的cpu问题能不能找到在哪
1個讚
我首先先看看 WebAPI 的问题，这个性能问题太严重了。
至于 UTP 问题，之前看 CPU 干活的情况应该就是低效的字节复制导致的。
1個讚
@wxhere15 我录制了两段视频，演示我这里严重的 WebAPI 问题
其中一个视频是只启动了一个下载任务，演示了 WebAPI 以合理的性能正常工作。
另一个视频是启动了 50+ 个下载任务，演示了任务较多的情况下，WebAPI 出现了严重的性能问题。
由于文件较大且论坛不支持上传附件，所以直接发送到您的邮箱中了。
收到邮件了，谢谢。我看看
@2908803755 我看你视频里开了很多任务，但上传下载速度很慢，是不是开了全局限速？
network.ignore_remote_access_in_speed_limit 目前只解除了remote_access的上传限速，下载限速的处理忘了做了。如果你设置了全局下载限速，可能会有影响。我打包个新版你再测试一下吧
1個讚
解除限速后，任务的数据处理会占用更多CPU时间。新版我发你邮箱了，看看限速情况下是否有改善吧，至少排除掉一个因素
专家模式看看界面卡的时候，统计中，消息队列里面显示什么？
观察下avg平均处理消息的延迟