性能测试
这一页记录的是一组基准测试结果，而不是“永远正确的性能结论”。
如果你要引用这些数据，最重要的不是只看数字，而是先理解测试对象、边界条件和它不包含什么。
本报告比较了四个Java Web框架的性能：Feat、Vert.x、Quarkus和Spring Boot。测试使用wrk工具，针对每个框架的Hello World和JSON响应接口进行了性能测试。
测试参数：4个线程，100个连接，持续60秒，开启延迟统计。
测试结论
根据测试结果，可以得出以下结论：
- 在JSON响应接口测试中，Feat框架表现最佳，每秒处理请求数最多。
- 在Hello World接口测试中，Feat框架表现最佳，每秒处理请求数最多。
Hello World
Section titled “Hello World”
JSON 响应
Section titled “JSON 响应”
| 测试类型 | 框架 | 每秒请求数 | 平均响应时间 (ms) | 错误率 (%) |
|---|---|---|---|---|
| Hello World | Feat | 158588.49 | 0.83 | 0.00 |
| Hello World | Quarkus | 80539.40 | 1.55 | 0.00 |
| Hello World | Spring Boot | 39952.10 | 3.87 | 0.00 |
| Hello World | Vert.x | 84842.99 | 1.29 | 0.00 |
| JSON 响应 | Feat | 158186.41 | 0.92 | 0.00 |
| JSON 响应 | Quarkus | 81771.06 | 1.60 | 0.00 |
| JSON 响应 | Spring Boot | 40531.54 | 2.47 | 0.00 |
| JSON 响应 | Vert.x | 77179.81 | 1.40 | 0.00 |
这组数据应该怎么解读
Section titled “这组数据应该怎么解读”这组基准测试最适合支持下面这种判断：
- 在“非常轻的 HTTP 接口”场景下，Feat 的底座性能没有成为瓶颈
- Feat 在简单请求路径上的吞吐能力是它的重要卖点之一
它不适合直接支持下面这些过度推断：
- “所有真实业务场景里 Feat 都一定更快”
- “换成 Feat 就一定能立刻省掉同等比例的机器成本”
- “复杂业务系统的整体延迟一定会按同样比例下降”
什么时候这页有价值
Section titled “什么时候这页有价值”这页最有价值的使用方式通常有三种：
- 你在做技术选型，需要知道 Feat 的底层性能大致处在什么级别
- 你已经确定要用 Feat，希望知道它适不适合高吞吐、低延迟场景
- 你在给团队解释为什么 Feat 的设计会从服务底座出发
如果你要做自己的性能测试
Section titled “如果你要做自己的性能测试”不要照搬这页里的结论，直接套到自己系统上。
更合理的做法是：
- 保持业务逻辑尽量等价
- 固定硬件、JDK、并发和网络环境
- 区分“框架基准”和“业务基准”
- 先看吞吐，再看尾延迟和资源占用
如果你真正关心的是你的系统，而不是框架宣传页，那么自己的压测结果一定比这页更重要。