并发不高的话问题应该不大，还有个商业模式可以禁用一些中间件优化高并发表现。不过团队用一般还要前面套一层newapi管分发吧？两个加起来可能2c2g还是更稳一点
完全足够
实时请求 100rpm 的容器占用：
CPU 使用 CPU 总计 核心数 94.96 ms 12.18s 0
内存使用 缓存使用 内存限额 298.63 MiB 0 B 31.34 GiB
我就是用azure-jp跑的，毫无压力，就是流量每个月消耗两三百g
azure jp b2pts搭了newapi+cpa+cpakeeper，完全没有问题
@waterflow #11 诶，不可以全部都使用一个key来访问么？会有速度或者是数据相互交叉的影响么？
@seenline #16 可以都用一个key，没有使用上的区别吧，就是不能区分每个人用了多少。万一有一个人太想进步了大蹬特蹬，其他人没怎么用就到限额了，用newapi分发就能看见是谁用了这么多
@Zendust #9 sub2api理论上比cpa重 所以1C1G跑cpa是没问题的
给你我三台小鸡上的数据，供参考哦： 自己轻量使用，一个池子里账号最多不超过两百个，小鸡跑起来好像没啥问题
1C1G：
1C2G：
2C2G：
@lzy2005 #15 真的假的，我也有有一台，实用内存不到800M
并发不高的话问题应该不大，还有个商业模式可以禁用一些中间件优化高并发表现。不过团队用一般还要前面套一层newapi管分发吧？两个加起来可能2c2g还是更稳一点
完全足够
实时请求 100rpm 的容器占用：
CPU 使用 CPU 总计 核心数
94.96 ms 12.18s 0
内存使用 缓存使用 内存限额
298.63 MiB 0 B 31.34 GiB
我就是用azure-jp跑的，毫无压力，就是流量每个月消耗两三百g
azure jp b2pts搭了newapi+cpa+cpakeeper，完全没有问题
@waterflow #11 诶，不可以全部都使用一个key来访问么？会有速度或者是数据相互交叉的影响么？
@seenline #16
可以都用一个key，没有使用上的区别吧，就是不能区分每个人用了多少。万一有一个人太想进步了大蹬特蹬，其他人没怎么用就到限额了，用newapi分发就能看见是谁用了这么多
@Zendust #9 sub2api理论上比cpa重 所以1C1G跑cpa是没问题的
给你我三台小鸡上的数据，供参考哦：
自己轻量使用，一个池子里账号最多不超过两百个，小鸡跑起来好像没啥问题
1C1G：
1C2G：
2C2G：
@lzy2005 #15
真的假的，我也有有一台，实用内存不到800M