性能工程不该等到用户投诉“系统变慢”才开始。围绕《Fast by Default: Practical Performance Engineering》作者 Den Odell 的讨论提出了一个更实用的问题：怎样在开发之初规划 Python 应用的性能，并把有限的工程资源投入真正影响用户体验的地方？答案通常不是到处做微优化，而是建立性能预算、用剖析数据定位瓶颈，并把关键指标纳入持续验证。
性能预算必须对应真实场景
“接口必须快”不是可执行的目标。有效的性能预算至少应明确工作负载、统计口径和资源上限。例如，一个搜索接口可以定义为：
- 在 50 个并发请求下，
p95响应时间不超过 200 ms。 - 单个应用实例每秒至少处理 300 个请求。
- 稳态内存不超过 512 MiB。
- 对典型输入，后台任务在 2 秒内完成。
这里的 p95 表示 95% 的请求耗时不超过目标值。只看平均值会掩盖慢请求，而只测一次本地运行也无法反映并发、缓存预热和数据规模带来的变化。
预算还需要分层。用户看到的总延迟，可以拆成网关、应用代码、数据库、外部 API 和序列化等部分。如果总预算是 200 ms，却允许数据库查询长期占用 180 ms，那么应用层几乎没有应对流量波动的余量。
先剖析，再决定优化哪里
Python 程序慢，可能是算法复杂度、重复 I/O、数据库往返、对象分配，也可能是锁竞争。仅凭代码观感判断，容易把时间花在调用频繁但总耗时很低的函数上。
可以先用标准库 cProfile 建立一个可重复的基线。下面的脚本故意包含低效的成员查找，能够直接运行：
# profile_demo.py
import cProfile
import io
import pstats
import random
def find_matches(records: list[int], allowed: list[int]) -> list[int]:
return [record for record in records if record in allowed]
def workload() -> None:
random.seed(42)
records = [random.randrange(100_000) for _ in range(200_000)]
allowed = list(range(0, 100_000, 10))
result = find_matches(records, allowed)
assert result
def main() -> None:
profiler = cProfile.Profile()
profiler.enable()
workload()
profiler.disable()
output = io.StringIO()
stats = pstats.Stats(profiler, stream=output)
stats.strip_dirs().sort_stats("cumulative").print_stats(12)
print(output.getvalue())
if __name__ == "__main__":
main()
运行：
python profile_demo.py
结果会按累计耗时列出热点。这个示例的主要问题是 record in allowed 对列表执行线性查找。可以这样实践：在进入循环前把 allowed 转成集合，让成员测试通常具有常数级平均复杂度。
def find_matches(records: list[int], allowed: list[int]) -> list[int]:
allowed_set = set(allowed)
return [record for record in records if record in allowed_set]
优化后应使用相同的 Python 版本、输入数据和运行环境重新测量。只有基线一致，前后数据才有比较价值。对于 Web 服务，还应补充端到端压测，因为函数级剖析无法完整呈现网络、数据库连接池和队列等待时间。
把性能约束写进自动化检查
性能数据存在噪声，不适合把单次耗时直接写成极窄的断言。不过，对稳定且关键的纯计算路径，可以设置有余量的回归阈值。以下示例可以保存为 test_performance.py，并与前面的脚本放在同一目录：
import random
import time
from profile_demo import find_matches
def test_find_matches_performance() -> None:
random.seed(42)
records = [random.randrange(100_000) for _ in range(200_000)]
allowed = list(range(0, 100_000, 10))
started = time.perf_counter()
result = find_matches(records, allowed)
elapsed = time.perf_counter() - started
assert result
assert elapsed < 0.25, f"performance budget exceeded: {elapsed:.3f}s"
执行命令：
python -m pip install pytest
pytest -q
运行前需要根据 CI 机器性能调整 0.25 秒阈值。更成熟的项目可以保存多次运行的分布，比较中位数或高百分位，并在固定规格的执行器上运行性能测试。端到端服务则更适合用独立压测任务观察吞吐量、p95 和错误率，避免把环境抖动误判为代码回归。
优化资源应该投向哪里
性能工程也是资源分配问题。可以按下面的顺序判断：
- 找出最重要的用户路径，例如登录、搜索、结账或任务提交。
- 记录当前基线，包括延迟分位数、吞吐量、CPU、内存和 I/O。
- 用剖析工具确认时间和资源实际消耗在哪里。
- 优先处理同时具备高频、高成本和用户可感知特征的瓶颈。
- 优化后验证功能正确性，并在相同条件下重新测量。
- 把关键预算放入持续集成或定期性能任务。
不要为了缩短几微秒而牺牲可读性，也不要把增加缓存视为零成本方案。缓存会引入失效策略、内存占用和一致性问题；并发可能提高吞吐量，却也会放大数据库压力；更快的算法有时需要更多内存。性能预算的价值，正是让这些取舍有明确边界。
落地检查表
开始实施时，可以先选择一条业务关键路径，而不是立即覆盖整个系统。确认它有真实工作负载、稳定基线和清晰预算；通过剖析找到主要瓶颈；只提交能够被数据证明的优化；最后建立回归检查。这样，“默认就快”不再依赖某次突击调优，而会成为架构决策、代码评审和发布流程共同维护的工程属性。