服務 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 延遲較低、每個 CPU 核心處理的請求較多，記憶體也用得較少。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、憑證、記錄、連線重用、回應大小與網路路徑都會影響結果。測試自己的部署時，應固定 Script 與參數，多跑幾輪，並同時記錄吞吐量、P99、錯誤率、CPU、記憶體與連線數。
- 正式部署必須保留餘量。若業務在意回應速度，應用真實請求測出可接受的併發上限，不要直接照搬本頁數字。