如何判断 web 业务模块初始上线时，需要多大磁盘，内存，带宽和 CPU

[lryepoch]

之前一直没有考虑过这个问题，每次需要服务器的时候，都竟可能想着参数越大就越好。但是，这样子肯定是有资源浪费的情况的。

有想过跟服务的用户数、QPS 等因素有关，但是还是想问问磁盘，内存，带宽，CPU 跟用户数、QPS 等等有什么可以量化的关系吗

[guisheng]

压测后得出结论后预估

[xinhero123]

压测+动态扩缩容

[xuanbg]

用户数是无法准确预估的，正确的做法是要具备动态的扩容能力。

[fisherwei]

首先预估出来你的业务场景占比，比如：
1 、典型请求 A ，20%比例，对应 4 次 SQL

[fisherwei]

上一条按错了，没写完发出去了。。。

2 、典型请求 B ，50%占比，对应 1 次 SQL
3 、典型请求 C ，xx%，对应 y 次 SQL

然后压测这几种场景，按照占比计算出来每 qps 对应的 cpu mem 的平均消耗，比如平均每 qps 需要 0.25 Mhz CPU 和 5k mem 。

最后按照这个数据套用一下，上线观测，修正，观测，修正。

最终，你会发现，由于现在机器便宜，这么做成本高，收益低。

[lryepoch]

@fisherwei 看上去好麻烦的样子

[Kinnice]

带宽：平均请求大小除一下就有了
磁盘：这个好估计，基本是看业务了
内存 /CPU：压测

[westoy]

我倒觉得这个其实是不存在的问题

如果团队有资源， 有牛逼的运营， 可以一上来就打爆， 那肯定要大量冗余的啊， 这问题就不需要考虑了

如果没有， 那按照正常的流量增长曲线去走就行了， 前期在能跑得动的基础上适当加点冗余就可以了， 这问题也不需要考虑啊

[Chinsung]

没什么量化关系，现在整个应用运行都太复杂了
一般微服务就单台 2 核 4g ，然后就是压测，再垃圾的压测也是压测

[Saxton]

看你们的推广团队了

[lizy0329]

可以参考其他业务的起步阶段