011、性能建模与容量规划
性能建模与容量规划：从一次深夜告警说起
凌晨两点，手机突然狂震。线上核心服务的响应时间曲线像坐了火箭，从平时的50毫秒直冲3000毫秒。登录监控系统一看，CPU使用率早已突破90%红线，数据库连接池全满。这不是第一次了——每次大促前我们都在拍脑袋扩容，但似乎永远猜不准该加多少机器。
性能建模不是算命
很多人把性能建模想象成某种玄学：盯着监控曲线，凭感觉说“再加两台吧”。真正的性能建模是基于数学的工程方法。我们得先搞清楚系统在压力下的行为模式。
拿那个出问题的服务来说，它的核心接口处理逻辑包含三个部分：本地计算（约5ms）、缓存查询（约2ms）、数据库写入（约15ms）。单看每个环节都不慢，但问题出在并发上。当每秒请求量超过1000时，数据库连接开始排队，排队时间很快成为主导因素。
# 简化的性能模型估算defestimate_latency(request_rate):# 基础处理时间base_time=5+2+15# 单位ms# 数据库连接池排队模型（这里踩过坑）# 原来用的简单除法，完全不对！# old_wrong_way: db_queue_time = request_rate / 100 * 10# M/M/c排队模型更接近现实# c是连接数，这里假设50个连接utilization=request_rate*0.015/50# 每个请求占用15ms，换算利用率ifutilization>=0.9:returnfloat('inf')# 系统要崩queue_time=