可以，稍等一下，我这里需要重启应用代码更改，中间会短暂 502。
完成的时候我编辑这个 post。
01:43 更新已完成
我看看 10% 的流量能产生多大负载。如果负载足够高的话，我可以看看把 Peers 表放内存里。不过目前不知道负载有多少，感觉可能会过度优化。
不过你准备如何调度呢？
代码更改已应用。
不过调度流量如何让用户把 Tracker 地址改过来？还是说做个反代之类的？
如果是反代的话，我这里可以设置读取特定的 HTTP 请求头，修正 Peer IP
可以协商一下，我这里也可以在内存里把 Peer IP 修正。
对的，反代重写，现在已经调度过去了，看看有什么负载问题了没有，没有的话应该就OK啦
反代重写的话，我这里识别不了 Peer 的 IP？
因为 BitComet 似乎不会把自己的 IP 放在查询参数里。反代的话就是反代服务器的 IP 了。
我这里看到请求了，QPS 在 150 左右的样子。
性能看着没问题，但是我发现了个 BUG，正在修，我带着请求头一起给你加上。
编辑1：暂定请求头为 X-Rewrite-Peer-IP，你可以在反代上重写这个头的值为真实 IP
我看到了一个巨大的数字，超出长整型的数值范围了，我修改一下。
编辑2：随机负数这个我也加一个
编辑3：现在QPS在50左右
编辑4：重启应用更新
正好在测试能不能用，tracker响应正常工作，随机时间也成功了（不过多次右键更新看起来只有+数值没有-），看起来没啥问题，opentracker对于单核心vps的性能瓶颈在1w3 qps，150qps没出问题可以了，，，之前试了github很多tracker服务端，50请求就崩溃挂了
，随机时间也成功了（不过多次右键更新看起来只有+数值没有-）
现在支持负数随机了
暂定请求头为
X-Rewrite-Peer-IP，你可以在反代上重写这个头的值为真实 IP
实装了
这个重定向可以保留几天吗，我跑个 profiler 看看性能瓶颈。
刚刚应该是瞬间并发，PostgreSQL 卡住了，我看程序本身 没啥问题。
现在在监控 pgsql 的查询情况，并发查询 5631，磁盘I/O 14,044,407
可以多加一点，我这里负载降下来了，现在 QOS 从 250~ 降到了 50~
刚刚应该成功调度了10%流量过去，现在总计是调度了20%，，，可能是这个原因
应该还是并发查询的问题。
现在一次 announce 要查询：
1*IP 数量 (写入 peers) + 1 (写入活动记录表) + 1 (更新 tasks 表) + 1 (查询 Peers 表) + 1(写入 clientDiscovery 表)
估计要做个队列。并发 329QPS
行，可以先停止转发了。我去优化一下。
opentracker 它全内存操作，太快了。
