之前一直没有考虑过这个问题,每次需要服务器的时候,都竟可能想着参数越大就越好。但是,这样子肯定是有资源浪费的情况的。
有想过跟服务的用户数、QPS 等因素有关,但是还是想问问磁盘,内存,带宽,CPU 跟用户数、QPS 等等有什么可以量化的关系吗
1
guisheng 2022-05-24 08:32:47 +08:00 via iPhone
压测后得出结论后预估
|
2
xinhero123 2022-05-24 08:38:24 +08:00
压测+动态扩缩容
|
3
xuanbg 2022-05-24 08:49:37 +08:00
用户数是无法准确预估的,正确的做法是要具备动态的扩容能力。
|
4
fisherwei 2022-05-24 10:22:18 +08:00
首先预估出来你的业务场景占比,比如:
1 、典型请求 A ,20%比例,对应 4 次 SQL |
5
fisherwei 2022-05-24 10:25:11 +08:00
上一条按错了,没写完发出去了。。。
2 、典型请求 B ,50%占比,对应 1 次 SQL 3 、典型请求 C ,xx%,对应 y 次 SQL 然后压测这几种场景,按照占比计算出来每 qps 对应的 cpu mem 的平均消耗,比如平均每 qps 需要 0.25 Mhz CPU 和 5k mem 。 最后按照这个数据套用一下,上线观测,修正,观测,修正。 最终,你会发现,由于现在机器便宜,这么做成本高,收益低。 |
7
Kinnice 2022-05-24 13:49:13 +08:00 via Android
带宽:平均请求大小除一下就有了
磁盘:这个好估计,基本是看业务了 内存 /CPU:压测 |
8
westoy 2022-05-24 13:53:08 +08:00
我倒觉得这个其实是不存在的问题
如果团队有资源, 有牛逼的运营, 可以一上来就打爆, 那肯定要大量冗余的啊, 这问题就不需要考虑了 如果没有, 那按照正常的流量增长曲线去走就行了, 前期在能跑得动的基础上适当加点冗余就可以了, 这问题也不需要考虑啊 |
9
Chinsung 2022-05-24 17:30:10 +08:00
没什么量化关系,现在整个应用运行都太复杂了
一般微服务就单台 2 核 4g ,然后就是压测,再垃圾的压测也是压测 |
10
Saxton 2022-05-24 17:31:29 +08:00
看你们的推广团队了
|
11
lizy0329 2022-05-25 10:22:28 +08:00
可以参考其他业务的起步阶段
|