서비스 CPU
fn-knock5.81 코어
다른 제품4.37 코어
성능 및 리소스 효율 벤치마크
fn-knock와 같은 종류의 다른 제품을 동일한 환경에서 같은 설정으로 부하 테스트했습니다. 아래 수치는 이번 테스트만 설명합니다. 제3자 인증이 아니며 하드웨어나 실제 서비스 트래픽이 달라지면 결과도 달라질 수 있습니다.
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가 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% 적음 |
fn-knock는 동시 연결 512에서 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, 메모리 및 연결 수를 함께 기록하세요.
- 운영 환경에는 여유를 남겨야 합니다. 응답 시간이 중요하다면 이 페이지의 수치를 그대로 쓰지 말고 실제 요청으로 허용 가능한 동시 연결 수를 확인하세요.