我这里看 60% 只有 227qps，比想象的低？
不清楚实际分过来的 qps 能到多少，不排除我这里请求队列满了不接连接的可能，但 CF 的监测看着还行
60%流量调度多少指的是只调度了其中一个客户端其中的60%流量
1個讚
这个客户端指的是一个客户端 IP，一个 Tracker 服务器还是一类客户端 （ut/bc）这种
一个客户端，你那应该只看到来自ut的流量
1個讚
是的，我这里看到了 uT 和迅雷（它的 UserAgent 是 uTorrent）的流量
能加个 10% 的 qb 看看吗，qb 我记得相对负载高一点
负载看到了，目前是 798qps，CPU 负载 46%
加 还可以加，再加个 20% 梭哈一把，再加 40% 吧。
现在 CPU 占用在 30-40% 的样子。优化效果已经超出预期了。Tracker 上目前注册了 50w 的 Peer，登记了 35w 的 Torrent，目前平均 800 qps。
没有看到额外qb的20%流量，我再等一会儿
看到了，目前负载 CPU 35%，QPS 668
qb4.x版本现在30%调度，加上去了
编辑
qb改成60%了，在看看呢
编辑
要不然我写个全客户端20%流量调度看看
1個讚
我觉得可以
负载看到了 3.73k QPS，CPU 58%
刚才调度了80%全客户端流量过去，应该有5k左右qps吧
编辑
看起来差不多，符合流量调度预期，现在凌晨就这么多并发了
1個讚
那今天的测试可以先结束了，目前稳定负载 4k QPS 左右应该不是问题
挺好的，应该能承担公共 tracker 流量没问题了
托管 Torrents 408661 个，Peers 601871 个。近 5 分钟 780052 请求次数。
1個讚
嗯，试了工作正常，这么看来优化还是很有效果的，从之前的50qps就崩溃，到现在4k qps没什么问题
1個讚
世界第一大tracker
sparkle tracker的性能测试可以说圆满结束了，通过当前50%左右占用CPU计算得出理论上能达到8K qps左右性能，跑起来没什么问题了，毕竟sparkle 本身定位不止是一个tracker，还需要额外处理数据
2個讚
可以试试启用ZRAM，用在数据库的系统缓存压缩效果比较好。
看起来没什么问题，工作很正常。(post deleted by author)
1個讚
QPS 目前在 1.2k 的样子
我看你(post deleted by author)了，十分钟前马上就停掉了
对因为我想起来开了个 CF 的请求速率限制，单 IP QOS 太高了就拒绝了。
暂时先不测了，我先去睡觉
完成了技术改造，现在切换到了 Redis (Valkey) 上，之前跑在 PostgreSQL 上面 Tracker 跑太高了影响核心服务。
设计上可承载 1000req/s，但应该还能更高。目前 hard-limit 是 5000 并发。具体承载多少可以测试一下。
在此期间改造了下述内容：
- 从 PGSQL 迁移到了 Redis 以解决数据库不堪重负的问题
- 改进了宣告队列，现在会异步刷写到 Redis 中，平滑宣告尖峰；如果宣告队列已满，会自动返回可重试错误，指示 BT 客户端短时间后再次尝试
- 添加了并发队列，控制同一时间对宣告端点的并发请求，避免部分错误配置的客户端的瞬间并发引发拒绝服务，如果并发队列达到上限，将立刻返回可重试错误，指示 BT 客户端失败的宣告应在短时间后再次尝试
- 开始将数据正式接入 BTN 反吸血网络分析，目前已经发现很多异常客户端（例如顶着
anacrolix/torrent的 UA 却宣告自己是 qBittorrent，或者顶着curl的 UA 却宣告自己是 qBittorrent/Transmission 等）
3個讚