한선씨 vs node vs bash HTTP 서버 성능 비교 (2026-06-14)
개요
amena.crowny.org 공개 443 복구 작업의 후속으로, 게이트웨이를 한선씨로 이관할 타당성을 측정으로 확인했다. 동일 워크로드(HTTP GET → 고정 JSON
{"ok":1}, Connection:close) 최소 서버를 한선씨(crownyc toau VM)·node(V8)·bash(nc fork) 3종으로 구현해 테스트 포트(19001~19003)에서 ab 벤치했다. 라이브 게이트웨이(443/8080 node, 9921 포털)는 건드리지 않았다.
측정 결과
| 런타임 | 기동시간 | idle RSS | 처리량(req/s) | 평균 latency | 실패 |
|---|
| 한선씨 (crownyc toau) | 34ms | 5.1MB | 26,008 | 0.384ms | 0 |
| node (V8) | 151ms | 39.2MB | 21,870 | 0.457ms | 0 |
| bash (nc fork-per-req) | — | 1.6MB | ~113 (순차) | 8.8ms | 0 |
- ab 조건: 한선씨·node =
-n 2000 -c 10, bash = 순차 20회(fork-per-request 한계로 동시부하 불가).
- 참고 — 라이브 한선씨 포털 9921
/api/health(실제 라우팅+인증 포함): 13,803 req/s, 0.362ms (-n 500 -c 5).
해석
- 한선씨 crownyc VM이 node 대비 메모리 7.7배 적고, 처리량 19% 높고, 기동 4.4배 빠르며 실패 0.
- bash는 요청마다 nc 프로세스를 fork해 약 230배 느림 — 게이트웨이 본체로는 부적합(런처 용도만).
- 실제 라우팅·인증이 들어간 라이브 포털도 13,800 req/s로 충분한 처리량.
공정성 한계 (정직)
- 단순 응답 워크로드 기준 — node는 복잡 비동기·JIT 워밍업 시나리오에서 달라질 수 있고, 한선씨 VM은 단일스레드이며 STR 풀 한계 등 기존 함정이 있다.
- 절대수치보다 차수(order) 비교로 볼 것. 그래도 기동·메모리·단순처리량 전 항목에서 한선씨 우위는 분명.
결론
게이트웨이 한선씨 이관 타당성이 측정으로 뒷받침된다(기동·메모리·처리량 모두 우위). 직전에 완성한
SNI생성기.한선(라이브 conf 동등+정확 검증, 이관 배치 완료)과 합쳐, 한선씨 경로(stunnel + 한선씨 8080 프록시)로의 전체 컷오버는
기능 패리티(WebSocket/SPA/static) 충족만 남았다.
관련 파일
- 벤치 서버:
/tmp/벤치서버.한선(+.toau) · /tmp/벤치서버.js · /tmp/벤치서버.sh
- 한선씨 게이트웨이 실행기:
/tmp/gwlive.toau(837KB), 한선게이트웨이/게이트웨이라이브.한선·게이트웨이통합.한선
- 이관 도구:
한선게이트웨이/SNI생성기.한선(+.rpn.한선)
- 지식셀 #9148, 메모리
project_gateway_hanseon
잔여
- 전체 컷오버 전제 = 기능 패리티(WS/SPA/static) 검증 (gateway 세션 담당, 별도 로드맵)
- amena-learn.crowny.org는 어느 cert SAN에도 없어 cert 신규 발급 필요