サービス 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
負荷テスト前
高負荷時平均
記録ピーク
クールダウン後
結果の概要
主なテストでは、2 つのゲートウェイに同じ 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 と 2 つの対象サービスが同じ 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 は CPU を 33.07% 多く使用 |
| スループット | 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% 少ない |
同時接続 512 では fn-knock の 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 がユーザーのアクセスを処理するゲートウェイです。2 つのリクエストは処理内容が違うため、数値を直接順位付けしたり、7998 からリバースプロキシ容量を推定したりできません。管理 API はアプリケーションの入口ではありません。公開する前に OpenAPI：管理 API の公開と AI Agentを確認してください。
この数値を使うときの注意
- 今回、fn-knock は同時接続 64 付近ですでにスループット上限に近づいていました。それ以上増やすと、主に待ち時間が増えます。
- fn-knock の短期的なメモリ使用量は少ない結果でしたが、長期安定性は継続テストで確認する必要があります。
- ログを無効にするかどうかは運用と監査の要件で決め、ベンチマークの点数だけで判断しないでください。
7998と7999は処理内容が違うため、2 つの結果を同じ順位表に入れないでください。
測定範囲と制限
- 主な 2 つの比較経路では、HTTPS、同じ Host、未一致ルートの 404 を使用しましたが、レスポンス本文のサイズは異なります。fn-knock は約 11.5 KiB、他製品は約 65 B でした。fn-knock はレスポンス本文が大きい状態でも高いスループットを記録しました。
- 今回は TLS、CIDR 判定、ルート照合、ゲートウェイが直接返す 404 を測定しました。特定のアップストリームアプリケーションは含まないため、すべての業務の実速度を示すものではありません。
- 「他製品」は今回使用したバージョンと設定だけを指します。他のバージョン、別のデプロイ方法、すべての同種製品をこの結果だけで判断できません。
- ハードウェア、カーネル、TLS、証明書、ログ、接続再利用、レスポンスサイズ、ネットワーク経路によって結果は変わります。自分の環境ではスクリプトと設定を固定して複数回実行し、スループット、P99、エラー率、CPU、メモリ、接続数を一緒に記録してください。
- 本番環境には余裕を残してください。応答時間を重視する場合は、このページの数値をそのまま使わず、実際のリクエストで許容できる同時接続数を確認してください。