昨晚提交了公共 Tracker 列表后，今天 Tracker QOS 一路飞升。
看了一下 hp/torrent 和 dt/torrent 已经开始疯狂刷 Tracker 了。
话说我同时运行几百个做种任务，加上了这个Tracker，不知道负载会如何。
这就是上方提到的差分技术了，把每个任务的时间错开，几百个任务算少的了，挂几万任务的人很多的
考虑到下载的人都会去请求这个Tracker，所以不好说负载如何。
负载昨晚测试的结果是50请求就崩溃了，看今天优化的怎么样了吧，看了下github提交记录，今天提交了几十个代码更新
而且BitComet在开启做种任务的时候，是会同时请求的，所以会带来瞬时的高并发。
现在 150 qps 可以稳定了，具体能到多高还没测，但昨晚的压力是没问题了。
虽说BitComet在返回结果无效时会逐步延长等待时间，但还是会容易产生雪崩。
我来试试看。
这个没办法，所有bt软件都是这样的，等待成功后返回时间就行了，有了差分技术后，BT软件后续产生的请求时间就错开了
这是BEP协议规定这么做的
所以还是尽量确保实际可以处理的上限高于预期并发的50%~75%比较好。
我看大部分在5s以内会有响应，但少数有20~30s不等的响应时延。
有 announce 并发控制，Sparkle 目前设置最多同时处理 200 个 announce，其它的会等待。
我会看情况调整这个并发设置。
如果可以的话，可以把加减现有预期更新间隔的一半作为更新时间变化的幅度，这样的话可以充分均分请求的密度，尽可能削峰，理论上可以做到服务实际处理QPS上限的1800倍个种子的查询请求。
别这么干，用户IP改变，系统唤醒，程序退出会同时announce所有种子。还是会死的，不会解决根本问题。
现在已经有这个机制了。
确实是这个作用，但是不能减少请求量，该有的还是有的，就和帖子里面的图片显示一样，让CPU变得一条线平滑起来，不会出现高峰占用
加减一般在6分钟内比较好，也就是上下3分钟，看了下sparkle的源码目前是上下30秒，可以适当改大点
减少请求量的唯一有效手段就是增长时间，例如通知客户端下次更新时间为2小时，甚至24小时
测试可以随时开始
现在正好是晚高峰，先调度10%流量试一下，规则部署上去节点了
