服务 CPU
fn-knock5.81 核
其他产品4.37 核
性能与资源效率测试
我们把 fn-knock 和另一款同类产品放在同一套环境里，用相同参数做了一轮压力测试。下面的数据只代表这次测试，不是第三方认证，也不保证换一套硬件或真实业务后仍会得到相同结果。
64 并发
fn-knock13,529
其他产品2,992
256 并发
fn-knock12,982
其他产品4,251
512 并发
fn-knock13,026
其他产品4,642
64 并发
fn-knock30.38
其他产品81.52
256 并发
fn-knock242.29
其他产品272.92
512 并发
fn-knock498.68
其他产品573.10
每核吞吐
fn-knock2,242 req/s/核
其他产品1,063 req/s/核
平均内存（RSS）
fn-knock153.4 MiB
其他产品325.6 MiB
压测前
高负载平均
历史峰值
冷却后
结论摘要
主要测试内容是让两个网关处理相同的 HTTPS 404 请求。在这组数据里，fn-knock 的吞吐更高，P99 延迟更低，每核处理的请求更多，内存占用也更少。P99 表示 99% 的请求都能在这个时间内完成，数值越低越好。
| 指标 | fn-knock | 其他产品 | 结果 |
|---|---|---|---|
| 512 并发吞吐 | 13,026 req/s | 4,642 req/s | fn-knock 为 2.81× |
| 512 并发 P99 | 498.68 ms | 573.10 ms | fn-knock 低 12.99% |
| 每核吞吐 | 2,242 req/s/核 | 1,063 req/s/核 | fn-knock 高 110.89% |
| 高负载平均内存（RSS） | 153.4 MiB | 325.6 MiB | fn-knock 少 52.90% |
关闭回环地址的请求日志后，fn-knock 的吞吐基本不变，P99、CPU 和内存波动略有下降，这批压测请求也不再写入访问日志。
测试条件
| 项目 | 设置 |
|---|---|
| 测试日期 | 2026-07-31 |
| 发压工具 | wrk，8 个线程 |
| 并发级别 | 64、256、512 |
| 主要请求 | HTTPS，请求 Host 为 loadtest.invalid，命中未匹配路由并返回 404 |
| 资源记录 | 使用 pidstat 记录目标服务进程的 CPU 和 RSS 平均值；RSS 可理解为进程实际占用的物理内存 |
| 测试环境 | wrk 和两个被测服务共用同一套 8 核资源；每一轮都使用相同的工具和并发参数 |
这样可以尽量减少网络路径带来的差异，但 wrk 本身也会占用 CPU。换句话说，这些数字是整套 8 核环境一起跑出来的结果，不是服务独占硬件时的上限，也没有计入真实公网延迟。
吞吐与 P99 延迟
| 并发 | fn-knock 吞吐 | 其他产品吞吐 | fn-knock 吞吐优势 | fn-knock P99 | 其他产品 P99 |
|---|---|---|---|---|---|
| 64 | 13,529 req/s | 2,992 req/s | 352.14% | 30.38 ms | 81.52 ms |
| 256 | 12,982 req/s | 4,251 req/s | 205.36% | 242.29 ms | 272.92 ms |
| 512 | 13,026 req/s | 4,642 req/s | 180.63% | 498.68 ms | 573.10 ms |
fn-knock 在 64 并发时已经达到约 13.5k req/s。继续增加并发，吞吐没有明显提高，等待时间却变长了。其他产品从 256 增加到 512 并发时，吞吐只增加约 9.2%，P99 却增加约 110%。也就是说，再堆并发已经很难换来同比例的吞吐，反而会明显拉高延迟。
512 并发下的资源效率
| 指标 | fn-knock | 其他产品 | 解读 |
|---|---|---|---|
| 服务 CPU | 5.81 核 | 4.37 核 | fn-knock 多使用 33.07% CPU |
| 吞吐 | 13,026 req/s | 4,642 req/s | fn-knock 多处理 180.63% 请求 |
| 每核吞吐 | 2,242 req/s/核 | 1,063 req/s/核 | fn-knock 高 110.89% |
| 高负载平均内存（RSS） | 153.4 MiB | 325.6 MiB | fn-knock 少 52.90% |
fn-knock 在 512 并发时用了更多 CPU，但多处理的请求远高于 CPU 增幅，所以每个 CPU 核心完成的工作仍然更多。CPU 占用不能单独看，还要一起看吞吐、P99 和错误率。
压测前后的内存变化
| 阶段 | fn-knock | 其他产品 | 其他产品 / fn-knock |
|---|---|---|---|
| 压测前 | 58.3 MiB | 121.4 MiB | 2.08× |
| 高负载平均 | 153.4 MiB | 325.6 MiB | 2.12× |
| 历史峰值 | 228.6 MiB | 610.0 MiB | 2.67× |
| 同轮冷却后 | 132.8 MiB | 201.7 MiB | 1.52× |
其他产品的内存峰值达到 610.0 MiB。再次压测时，它出现了 6 次超时，P99 一度达到 1.12 秒。fn-knock 在复测中没有超时，内存峰值也没有继续升高。
这次复测时间不长，只能看出短期的内存峰值和回落情况。要判断内存是否会持续增长或存在泄漏，还需要用固定请求连续运行 30–60 分钟以上，并重复测试多轮。
关闭压测请求日志后的变化
关闭 fn-knock 的回环地址请求日志后，与上一轮开启日志时相比：
| 并发 | 吞吐变化 | P99 变化 | 平均延迟变化 |
|---|---|---|---|
| 64 | −4.06% | −13.52% | +0.67% |
| 256 | −0.72% | −10.63% | −10.08% |
| 512 | +0.32% | −6.83% | −5.03% |
512 并发下的吞吐只相差 0.32%，基本可以看作测试波动。P99 下降 6.83%，CPU 平均值下降 0.96%，平均内存下降 5.39%。这一轮共发出 593,792 次请求，访问日志没有增加。
从结果看，请求日志不是这次测试的主要性能瓶颈。关闭它不会明显提高 RPS，主要作用是减少磁盘写入，让 CPU 和内存更平稳。正式使用时是否记录回环地址或可信来源的请求，仍应根据审计、存储和排障需求决定。
7998 管理 API 不能和网关直接比较
测试时也顺手记录了 7998 管理 API 的 readiness 请求，数据如下：
| 路径 | 请求内容 | 吞吐 | P99 | 服务 CPU | 平均内存（RSS） |
|---|---|---|---|---|---|
fn-knock 网关 7999 | HTTPS 404、CIDR 判断与路由 | 13,026 req/s | 498.68 ms | 5.81 核 | 153.4 MiB |
| 其他产品 | HTTPS 404 | 4,642 req/s | 573.10 ms | 4.37 核 | 325.6 MiB |
管理 API 7998 | HTTP readiness，包含网关状态检查 | 5,157 req/s | 162.46 ms | 2.01 核 | 169.3 MiB |
7998 是管理接口，7999 才是处理用户访问的网关。两种请求做的工作不同，不能拿来直接排名，也不能用 7998 的数字估算反向代理能力。管理 API 不应作为业务入口；需要开放它时，请先阅读 OpenAPI：开放管理 API 与 AI Agent。
使用这些数据时要注意
- 这次测试中，fn-knock 在 64 并发附近已经接近吞吐上限。继续增加并发，主要增加的是等待时间。
- fn-knock 的短时内存占用更低，但是否长期稳定仍要靠更长时间的持续压测确认。
- 日志是否关闭要看实际审计和排障需求，不应只为了让跑分更好看。
7998和7999处理的请求不同，不要把两组数据放在一起排名。
口径与限制
- 两条主要对比路径都使用 HTTPS、相同 Host 和未匹配路由 404，但响应体不同：fn-knock 约 11.5 KiB，其他产品约 65 B。fn-knock 在响应体更大的情况下仍取得更高吞吐。
- 这轮测试只覆盖 TLS、CIDR 判断、路由匹配和网关直接返回 404，没有接入具体的上游应用，因此不能代表所有业务的实际速度。
- “其他产品”只指这次测试使用的版本和配置，不能据此判断它的其他版本、其他部署方式或所有同类产品。
- 硬件、系统内核、TLS、证书、日志、连接复用、响应大小和网络路径都会影响结果。测试自己的部署时，应固定脚本和参数，多跑几轮，并同时记录吞吐、P99、错误率、CPU、内存和连接数。
- 实际部署必须留出余量。如果业务在意响应速度，应按真实请求测试可接受的并发上限，不要直接照搬本页数字。