性能基准概念：定义毫秒级响应、性能指标
做性能调优之前，得先弄明白我们在调什么。
我刚入行那年，接过一个SDK，客户反馈“卡”。我二话不说开始改代码、加缓存，忙活了两周。结果上线一测——响应时间从800ms降到了750ms。老板问我：“不是说毫秒级吗？这算优化了个寂寞？”
嗯，那会儿我才意识到，连“毫秒级”都没定义清楚，优化就是瞎忙活。
这一章我们就先把概念打牢。不啰嗦，直接开干。
什么是毫秒级响应
说白了，就是用户从发起请求到收到完整结果，耗时在毫秒级别。
注意，是端到端的延迟。不是函数执行时间，也不是网络往返时间。是从SDK调用入口到回调触发那一刻，全部加起来。
我个人习惯把毫秒级拆成三层：
- 网络层：DNS、TCP握手、TLS握手，能吃掉几十到几百毫秒。
- 业务层：SDK内部逻辑、数据拼装、加解密。
- 等待层：队列排队、线程调度、GC停顿。
你想想看，前两层都优化到极致了，结果一个GC暂停让用户等了50ms，还是不够“毫秒级”。所以调优必须看全链路。
性能指标全景
有时候你跟后端同学聊，他们爱说“QPS多少”。跟QA聊，他们关心“响应时间”。跟老板聊，他只看“用户数”。
其实就四个核心指标，把他们都捋顺了，沟通就简单了。
| 指标 | 定义 | 典型单位 | 关注点 |
|---|---|---|---|
| 响应时间 | 请求发出到收到完整响应的耗时 | ms, s | 用户体验直接感觉 |
| 吞吐量 | 单位时间内能处理的请求数 | tps, qps, rps | 系统容量、压测标尺 |
| 并发用户数 | 同一时刻正在与系统交互的用户数 | 个 | 架构伸缩性、资源瓶颈 |
| 毫秒级响应 | 端到端延迟落在毫秒区间 | ms | 调优目标、SLA 基线 |
注意，这四个指标互相影响。比如并发高了，响应时间通常会涨，吞吐量反而可能下降（临界点之后）。调优就是找那个平衡点。
响应时间
响应时间是最直观的。用户按了按钮，他要等多久才能看到结果？
我曾经在调一个图片加载SDK时，发现中位数响应时间只有20ms，但P99却飙到800ms。排查后发现是有个线程池在高峰时频繁创建销毁线程。你说中位数看着挺美，可那1%的用户已经在摔手机了。
所以看响应时间，我建议至少关注三个分位值：
- P50：中位数，反映一般体验。
- P95：大部分用户的上限。
- P99：最差那一小撮用户，常藏着你没发现的坑。
吞吐量
吞吐量反映的是系统的“干活能力”。比如一个SDK每秒能处理多少次背单词查询。
单位常见的有：
- QPS（每秒查询数）——侧重读场景。
- TPS（每秒事务数）——侧重完整事务（含写）。
- RPS（每秒请求数）——HTTP/RPC场景。
我的习惯是：如果SDK既有读又有写，统一用TPS，这样不容易混淆。你想想看，外面宣传“百万QPS”，里面一半是缓存命中——这种指标就没太大参考价值。
吞吐量过高有个坑：资源耗尽。我曾经调过推送SDK，把吞吐量从2000 tps提到8000 tps，结果CPU打满，响应时间直接崩到2秒。这就是典型的“用吞吐换延迟”。
并发用户数
这个指标常常被误解。并发用户数不是“在线用户数”，也不是“注册用户数”。它指的是在同一时间点正在发请求的用户数。
比如一个IM SDK，你可能有一亿注册用户，但同一时刻只有1000人发消息，那并发用户就是1000。
并发用户数直接决定了你需要配多少线程、连接池、内存。我记得有一次压测，我用了500并发，响应时间没问题。但场景换到1000并发时，发现SDK内部有段同步代码变成了串行——嗯，锁的竞争导致性能断崖下降。
实战中我一般这么评估：
- 低并发（< 100）：常见于工具类SDK，单用户场景。
- 中并发（100-1000）：社交、电商SDK常见。
- 高并发（> 1000）：直播、游戏、大规模消息推送。
每个等级的策略不一样。低并发主要优化延迟，高并发得关注锁和上下文切换。
这四个概念就像工具箱里的四把尺子。只有都量全了，你才知道SDK到底弱在哪。