同步性能优化（四）

食言了，这个系列出现了第四篇，上篇遗留的问题是，调度器优化的实现代码，经过实验证明，上一篇所说的方案，在实际操作上，需要调整，并不是一个无脑实现即可的主意。

相关 PR：https://github.com/nervosnetwork/ckb/pull/2067

刚开始，我当真天真得以为，只要通过中位数进行分类，对超出中位数的响应阶段进行缓慢逐出卷可以非常完美地达到利用率的相对完美。而实际上的效果是，在前十分钟，效果不错，之后，效果反而比不动态调整时更差了，在一顿操作之后发现，不是调整值的问题，回过头来继续审视方案，发现了问题：

调度器的目的是为了让相对好的节点留下来，并能基本保证达到最大任务数
以中位数做分界点进行奖励与惩罚调整在一定时间内是没有问题的，它可以逐出相对差的节点
在初步逐出完成后，如果继续按中位数逐出，会导致内卷——自我竞争，其结果是要么节点任务数无法达到最大值，要么节点被逐出，最后导致能稳定连接的节点不多且任务数不满，新加入的节点被很快逐出

大概很多人注意到了，这个调度器用的方法是博弈论，而不是完全公平性调度。在囚徒困境中，一次抉择与长期的多次的抉择对整个博弈结果的影响是完全不一样的，进而选择的应对方式就完全不同，而我们很多时候更关注一次抉择的影响，这其实也是为什么我脑子里的第一个思路是全用中位数进行划分的原因。

目前在 PR 里的参数是实际环境下测试出来最稳定、效果最好的一组，但是，该参数的生成并没有特别的数据依据，大概属于拍脑袋之后的调参产物。即使如此，这组参数的数据也很好看，2333，比 develop 平均能高 10-20% 的同步性能。

当然，后面还需要进一步用数据去支持参数的选择，但它的参数有点多：

然后就可以开心的玄学调参了，找出相对好的数据再上真实网络调整。

这整个优化过程里，在思考的整体方向上来说，在于节点本身，用它的视角去观察网络世界和自身的性能，但实际上，站在被同步节点的角度来看，如果多个节点同时对它进行暴力同步，哪怕它用最好的性能做响应，在对方看来都会有不同程度上的延时。平衡网络负载和下载速度并不是不需要考虑的问题。

这次大规模长时间优化，更多的是在验证资源（串行阻塞验证）给定的情况下优化网络资源利用率，然后在网络资源利用率提高的时候，进一步压榨 CPU 资源，相辅相成，当然，后续要做的是验证资源的优化，现在的验证并没有达到最佳性能。