这是我之前在网上看到的,就保存了下,具体出处记不清了:
在新业务上线前,要得出你需要多大机器,你需要:(QPS*ART)/NOW=1。
- QPS = Queries per Second. 每秒请求数量,也就是所谓的「并发量」。
- ART = Average Response Time. 平均响应时间,单位秒。
- NOW = Number of Workers. PHP-FPM Worker 的数量。
根据单位推算,这个公式可以写为 (N/s*s)/N = 1,因此成立。
假设 QPS = 1000,ART = 0.1s,那么 NOW 为 100 才能够在理想状态下,刚好满足你的业务需求(也就是所有请求都可以在不排队的情况下完成处理)。
那么为了推算 NOW,你就需要知道 ART。你可以在一台 1 核心 CPU 的机器上跑一下你的业务,PHP-FPM max_children 保持为 1 即可。随后用压测工具跑单并发,即可计算大概的平均响应时间。务必单线程,否则没有参考价值。
得到 NOW,也就是所需的 Worker 数量之后,你就可以开始推算需要多大机器了。
一般来说,Worker 进程不建议超过 CPU 核心数的 2~4 倍。因此你可以使用 NOW / 2 甚至 NOW / 4 得到你所需要的 CPU 核心数。
至于内存,你同样可以在一台内存足够的机器上跑一跑你的业务,max_children 调大些,通过 systemctl 之类的工具观察 FPM Worker 进程的内存占用,得出一个大概内存占用量的大概数值,随后将平均内存占用量 * NOW 即可。
最后,在生产环境中,建议你:
- 先按照推算数量向上提高一个档位,部署一台机器。
- 随后通过 htop 等工具观察实际的 CPU 和内存使用率,尤其是 Load Average 的值。
- 如果比较稳定或者偏低,可以再降低一个档位部署一台机器(先不要销毁老机器)。
- 随后在业务低峰将 DNS 记录指向新机器,注意 DNS 记录的 TTL 不要太高。
- 观察新机器的 Load Average,如果偏高或者雪崩可以立即将 DNS Record 回滚到老机器,恭喜你找到了适合你的机型。如果仍然偏低,可以继续循环第 3 - 5 步,最终实践出最适合你的 Instance Type。
业务不一样,技术栈不一样,代码质量不一样,每个功能的难易程度和开销肯定不一样,肯定不能有一个万能的公式计算。 最这个第一步肯定是要进行压力测试,得出一台服务器能够处理QPS。 然后根据用户量,访问峰值,增长趋势等结合起来才能预估。
业务不一样,技术栈不一样,代码质量不一样,每个功能的难易程度和开销肯定不一样,肯定不能有一个万能的公式计算。 最这个第一步肯定是要进行压力测试,得出一台服务器能够处理QPS。 然后根据用户量,访问峰值,增长趋势等结合起来才能预估。