ps：加了pr链接帖子就发布出来，所以就不加链接了，可以自己去找对应的PR
搞了共享sub2之后我的服务器cpu一直100%，都要冒烟了，没办法只能想办法优化了。之后就给sub2api提交了13个PR，现在也是全部合并了。sub2api的性能将要提升一大截啦！
每次调度账号时，debug日志会for循环打印全部账号调试信息。但是如果没开debug也会循环打印，然后日志被丢弃。添加了一个判断，如果不是debug就不执行循环了，账号非常多时，cpu占用下降明显。
原本 scheduler_outbox 使用后不清理，导致表巨大，数据库要炸了。
PR添加了清理表的代码
原本无论并发是否已满，都会把请求加入排队队列，每次请求都会调用 Redis 队列，虽然说这个速度很快，但是高并发对cpu消耗还是很大的。
PR优化了，如果请求能直接成功，就不调用 Redis 队列了，只有并发不够时才去排队，其实大多数情况下并发其实都够用不用排队。
原本在上游请求失败时，会重复读取将要发给上游的请求体，并替换映射模型，账号失效比较多的时候，一个请求体可能被重复读取30次，在codex中一个请求体约4M左右，请求多的时候，对cpu的开销还是很大的。
对重复读取请求体做了优化，现在如果模型映射补发生改变就不会重复读取，每次请求只读取1次。
原本 token 刷新时会从数据库拉取全部启用的账号，然后在go语言中for循环判断是否需要刷新，我几百万个账号，每次刷新服务器都要爆炸 
。
现在改成只从数据库拉取需要刷新的账号，之后在go语言中刷新，服务器压力小多了。
然后还要几个是添加数据库索引，数据库查询更快，这些优化太小了就不写了。
我的pr已经都被合并了，下个版本sub2api的性能会有飞的提升！
DeH40_Sung (DeH40 Sung) 2
佬，你是怎么搞到这么多账号的 
youku 3
几百万的账号，恐怖啊，这是商业中转么
wlnRes 4
token不问出处，账号不问来路
zhichao_l (vill) 6
牛大了，那我可要更新试试水了，虽然我的小鸡就几个人用
shihao (十号) 7
佬你刚刚说你几百万个账号？都是GPT吗
back (back) 8
早就发现了数据库没索引，所以佬的pr，走自动更新的流程，会自动加上索引吗？还是需要手动去数据库加才行？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。