性能测试说明
This content is not available in your language yet.
这一页记录的是一组基准测试结果，而不是“永远正确的性能结论”。
如果你要引用这些数据，最重要的不是只看数字，而是先理解测试对象、边界条件和它不包含什么。
这组测试在测什么
Section titled “这组测试在测什么”这里比较的是三类 Java Web 框架在两个简单接口下的表现：
- Hello World
- JSON 响应
参与对比的对象：
- Feat
- Vert.x
- Spring Boot
测试工具是 Apache Benchmark（ab），测试参数为：
- 总请求数：
1,000,000 - 并发数：
100 - 启用 HTTP Keep-Alive
从这组测试里可以看到一个非常明确的趋势：
在当前测试条件下，Feat 在这两个简单接口上的吞吐和平均响应时间都表现得比较强。
Hello World
Section titled “Hello World”
JSON 响应
Section titled “JSON 响应”
| 测试类型 | 框架 | 每秒请求数 | 平均响应时间 (ms) | 错误率 (%) |
|---|---|---|---|---|
| Hello World | Feat | 88241.10 | 0.01 | 0.00 |
| Hello World | Spring Boot | 34406.30 | 0.03 | 0.00 |
| Hello World | Vert.x | 87304.32 | 0.01 | 0.00 |
| JSON 响应 | Feat | 89489.21 | 0.01 | 0.00 |
| JSON 响应 | Spring Boot | 10645.22 | 0.09 | 0.00 |
| JSON 响应 | Vert.x | 84135.96 | 0.01 | 0.00 |
这组数据应该怎么解读
Section titled “这组数据应该怎么解读”这组基准测试最适合支持下面这种判断：
- 在“非常轻的 HTTP 接口”场景下，Feat 的底座性能没有成为瓶颈
- Feat 在简单请求路径上的吞吐能力是它的重要卖点之一
它不适合直接支持下面这些过度推断：
- “所有真实业务场景里 Feat 都一定更快”
- “换成 Feat 就一定能立刻省掉同等比例的机器成本”
- “复杂业务系统的整体延迟一定会按同样比例下降”
什么时候这页有价值
Section titled “什么时候这页有价值”这页最有价值的使用方式通常有三种：
- 你在做技术选型，需要知道 Feat 的底层性能大致处在什么级别
- 你已经确定要用 Feat，希望知道它适不适合高吞吐、低延迟场景
- 你在给团队解释为什么 Feat 的设计会从服务底座出发
如果你要做自己的性能测试
Section titled “如果你要做自己的性能测试”不要照搬这页里的结论，直接套到自己系统上。
更合理的做法是：
- 保持业务逻辑尽量等价
- 固定硬件、JDK、并发和网络环境
- 区分“框架基准”和“业务基准”
- 先看吞吐，再看尾延迟和资源占用
如果你真正关心的是你的系统，而不是框架宣传页，那么自己的压测结果一定比这页更重要。