4. 性能评估指标：延迟、吞吐量、资源消耗、稳定性
做审计日志写入评估，光看QPS是远远不够的。你得把几个指标放在一起看，才能摸清系统的真实底细。
我以前就吃过亏。项目上线前，我就盯着QPS，测出来30万每秒，心里美滋滋。结果一压长稳，延迟飙上天，CPU直接打满，机器的硬盘还时不时卡一下……嗯，这次教训告诉我，四个指标一个都不能少。
4.1 延迟：别被平均值骗了
延迟是指一条日志从客户端发出到被服务端确认写入所花的时间。我习惯用毫秒衡量。很多人只看平均延迟，比如“平均5ms，不错啊”。但我告诉你，平均值最会骗人。
你想想看，99%的请求都是3ms，但剩下1%可能是300ms。平均下来也就6ms，看起来很美。可那个1%的长尾请求，哪个用户遇到了都会炸毛。
所以我建议重点关注这几个指标：
- P50（中位数）：大多数请求的表现
- P99：最差1%的请求，容忍度上限
- P999：极限情况，一般用于SLA严苛的场景
我曾经在一个金融项目中统计过，平均延迟只有8ms，但P99到了500ms。后来发现是因为批量写入时机没对齐，批次攒得太大。把每批大小从5000降到500，P99瞬间降到50ms。嗯，这个问题花了我一整天排查。
4.2 吞吐量：QPS到底能打多少
吞吐量就是单位时间能处理多少请求。对于审计日志，通常用写入QPS或每秒写入条数来衡量。
吞吐量跟延迟是一对冤家。利特尔定律讲得很清楚：并发数 = 吞吐量 × 延迟。如果你压上去的并发数不变，延迟涨了，吞吐量必然掉。
我建议用阶梯加压的方式来测吞吐量。具体做法：
- 从低并发开始，比如100个并发线程
- 每30秒记录一次QPS和延迟
- 稳定后增加并发（每次+50或+100）
- 直到延迟超过预定阈值（比如P99 > 200ms）或出现错误
- 那个临界点的QPS就是系统的最大可用吞吐量
4.3 资源消耗：机器扛得住吗
资源消耗直接决定你的部署成本和扩容策略。我主要看这四个方面：
| 资源类型 | 关键指标 | 我踩过的坑 |
|---|---|---|
| CPU | 使用率、sys/user占比 | 审计日志写入常涉及加解密，CPU一下子吃满 |
| 内存 | 堆内存、GC频率、Swap | 缓冲区没设上限，OOM直接挂掉 |
| 磁盘IO | IOPS、写入延迟、队列长度 | 写放大问题，SSD都扛不住频繁fsync |
| 网络 | 带宽使用率、TCP重传率 | 跨机房写入，带宽被打满丢包 |
我曾经在评估一个日志系统时，发现CPU使用率只有40%，但磁盘IO队列长度飙到20。后来发现是因为每次写入都调了fsync，把机械硬盘直接干废。改成批量刷盘后，队列长度降到2以下。你想想看，一个fsync调用就是一次磁盘同步，频率一高，系统全卡在IO上。
4.4 稳定性：别掉链子
稳定性是很多评估报告里一笔带过的东西。但没了稳定性，高QPS只是空中楼阁。我关心三个维度：
- 抖动：延迟是否忽高忽低。这种毛刺最恶心，可能几天一次，压测时很难发现。
- 长尾：P99和P50的差距。差距越大，系统越不稳定。
- 衰减：长时间运行后QPS和延迟是否逐渐恶化（比如内存泄漏、GC恶化）。
如果你用Golang或Rust，GC问题会少很多，但也别掉以轻心。协程池耗尽、连接池泄漏、磁盘调度策略变化，都会造成稳定性的滑坡。
4.5 指标综合分析：别当单指标动物
四个指标互相牵扯。举个典型场景：你提高并发来冲QPS，延迟可能会涨，资源消耗也会涨，一旦资源打满，稳定性瞬间崩塌。所以评估时不能只看一张图。
我习惯用下面的框架把四个指标串起来看：
说白了吧，这四个指标就是一张网。你拉吞吐量这根线，延迟和资源消耗就会绷紧；资源一紧，稳定性就松。所以我在写评估报告时，从来不会单独给一个QPS数字，而是给出类似这样的结论：
- 在P99延迟≤50ms、CPU≤70%、磁盘IO≤1000 IOPS的前提下，系统可持续支撑**25,000 QPS**。
- 超出该值后，延迟迅速恶化，资源消耗进入危险区。
好了，这四个指标的核心内容基本就这些。记住，压测的时候不要盯着一个数据傻乐，四个维度放在一起看，你的评估才真正有说服力。