4、性能基准测试：如何搭建测试环境、测试用例设计、基准数据的采集与分析

各位同学，今天我们聊一个非常实操的话题——性能基准测试。

说实话，很多团队做SOA服务，代码写完了，功能跑通了，就觉得万事大吉。结果一上车，延迟飙到几百毫秒，CPU直接拉满。为什么？因为没有做基准测试。我个人习惯是，在服务开发的第一天，就把基准测试环境搭好。这不是锦上添花，这是保命用的。

4.1 测试环境搭建：别让环境成为你的瓶颈

先说说环境。很多人在笔记本上跑测试，然后告诉我“延迟只有5毫秒”。我通常会反问一句：“你确定这不是在localhost上测的？”

基准测试的环境，必须尽可能接近真实部署环境。我建议你至少考虑以下几点：

• 硬件隔离：测试机不要跟开发机混用。我在项目中遇到过，测试时CPU被其他进程抢走，数据完全没法看。
• 网络环境：用真实的车载以太网交换机，别用路由器。车载网络有VLAN、有AVB/TSN，这些都会影响延迟。
• 资源限制：用cgroup或Docker限制CPU和内存。你想想看，如果测试时资源无限，那测出来的数据有什么参考价值？
• 时钟同步：分布式测试必须用PTP或gPTP同步时钟。否则你测出来的延迟，可能有一半是时钟偏差。

4.2 测试用例设计：覆盖场景，而不是覆盖代码

测试用例怎么设计？很多人上来就写一个循环，发1000次请求，算平均延迟。嗯，这其实不够。

我个人习惯把测试用例分成三类：

1. 轻负载场景：单客户端，单服务实例。目的是测出服务的“天花板延迟”。说白了，就是看看在没有竞争的情况下，服务到底能跑多快。
2. 重负载场景：多客户端并发，模拟真实车端场景。比如10个ECU同时请求同一个服务。这里要注意，并发数要合理。我曾经见过有人用1000个并发去测一个只有2核CPU的服务，结果全是超时，这没有意义。
3. 混合场景：不同服务混合调用，模拟真实业务流。比如同时调用车辆状态服务、导航服务、娱乐服务。这种场景最容易暴露资源争抢问题。

4.3 基准数据的采集：别只盯着平均值

数据采集，很多人只关注平均延迟。但说实话，平均值是最没用的指标。你想想看，如果99%的请求都在10ms内完成，但1%的请求花了500ms，平均值可能只有15ms。这能说明服务性能好吗？不能。

我建议你至少采集以下指标：

指标	说明	重点关注
P50延迟	50%的请求在此时间内完成	一般体验
P99延迟	99%的请求在此时间内完成	长尾延迟
P999延迟	99.9%的请求在此时间内完成	极端情况
吞吐量	每秒处理的请求数	系统容量
CPU/内存占用	服务运行时的资源消耗	资源瓶颈

采集工具方面，我个人推荐用 wrk 或 ghz 做压测，用 perf 或 bpftrace 做内核级分析。如果是gRPC服务，还可以用 ghz 的protobuf支持，直接发结构化数据。

4.4 数据分析：从数据中看出问题

数据采集完了，怎么分析？我一般分三步走：

1. 看分布，不看平均：用直方图或累积分布函数（CDF）看延迟分布。如果CDF曲线在尾部突然变陡，说明有长尾问题。
2. 找拐点：逐步增加并发数，观察延迟和吞吐量的变化。当吞吐量不再增加，延迟却急剧上升时，这个点就是系统的极限容量。
3. 关联分析：把延迟数据和CPU、内存、网络I/O关联起来。比如延迟升高时，CPU是否打满？网络是否有重传？

举个例子。我在一个项目中，发现P99延迟从10ms突然跳到200ms。看CPU，正常；看内存，正常；看网络，发现TCP重传率从0.1%升到了5%。最后定位到是交换机端口协商成了半双工。你看，不关联分析，根本找不到原因。

4.5 基准数据的版本管理

最后，别忘了给基准数据做版本管理。每次服务代码变更、配置变更、环境变更，都要重新跑一次基准测试，并把数据保存下来。

我习惯用 git-lfs 管理测试数据，每次提交代码时，同时提交一份测试报告。这样，当性能回退时，可以快速定位是哪个版本引入的问题。

好了，这一章就到这里。下一章我们聊聊如何分析性能瓶颈，我会分享一些我在实际项目中用到的工具和方法。

---

公众号:蓝海资料掘金营，微信deep3321