Akan.js Benchmark
Run: 2026-05-30T17-11-35-780Z
Akan.js 벤치마크 결과
Akan.js 2.0.7을 MacBook M4 Pro에서 측정해 HTTP, Signal API, document DB 경로의 실사용 성능을 확인했습니다. 목적은 단순합니다. 어느 정도 빠른지, 익숙한 프레임워크와 비교해 어디쯤 있는지, 그리고 실용적인 service-level target을 통과하는지 보여주는 것입니다.
요약
- 측정된 모든 Akan scenario는 throughput 및 p99 latency SLO를 통과했습니다.
- Pure HTTP는 119,571 RPS를 기록해 Bun 기반 minimal router 기준선과 같은 실용 범위에 있습니다.
- Signal API는 Akan의 API lifecycle을 실행하면서도 33,845 RPS를 기록했습니다. Application code 관점에서는 이 수치가 더 의미 있습니다.
- Document DB API도 list와 relation read를 포함해 목표 범위 안에 들어왔습니다.
성능 한눈에 보기
아래 bar는 독자가 먼저 궁금해하는 두 가지를 요약합니다. 각 Akan 경로가 SLO 대비 얼마나 여유가 있는지, 그리고 raw HTTP 경로가 익숙한 framework baseline과 비교해 어느 정도인지입니다.
항목별 SLO 여유
Pure HTTP
pure_http_no_db
2.4x RPS target, 6.2x p99 headroom
Signal API
signal_no_db
1.7x RPS target, 3.4x p99 headroom
DB Find
db_find_one
1.6x RPS target, 3.8x p99 headroom
DB List
db_list
1.1x RPS target, 1.3x p99 headroom
DB Relation
db_relation
10.8x RPS target, 11.5x p99 headroom
Minimal HTTP 비교
Document list와 storage ceiling
테스트 환경
벤치마크는 MacBook M4 Pro에서 Akan.js 2.0.7으로 로컬 실행했습니다. 로컬 벤치마크 수치는 machine state의 영향을 받지만, 일반적인 application API에 충분한 실용 성능 여유가 있는지 확인하기에는 유용합니다.
- Machine: MacBook M4 Pro
- Akan.js version: 2.0.7
- Akan runtime: Bun
- Akan mode: single-process local run
- Document store: SQLite
- Load profile: 50 virtual users, 10초 warmup, 30초 측정
- Latest focused seed size: document 300개
측정 항목
Pure HTTP
pure_http_no_db
최소 Akan HTTP route입니다. Business API 기능이 추가되기 전 framework의 low-level request handling 속도를 보여줍니다.
- 119,571 RPS 측정; 목표는 최소 50,000 RPS입니다.
- p99 latency는 0.812ms; 목표는 5ms 이하입니다.
- Peak RSS는 179.39MB입니다. 결과: SLO PASS.
Signal API
signal_no_db
DB 접근이 없는 일반 Akan Signal API 요청입니다. Akan application에서 사용자가 작성하는 API 스타일에 더 가까운 항목입니다.
- 33,845 RPS 측정; 목표는 최소 20,000 RPS입니다.
- p99 latency는 2.958ms; 목표는 10ms 이하입니다.
- Peak RSS는 199.23MB입니다. 결과: SLO PASS.
DB Find
db_find_one
Akan document API를 통한 단일 indexed document read입니다. 흔한 read endpoint 형태를 대표합니다.
- 16,274 RPS 측정; 목표는 최소 10,000 RPS입니다.
- p99 latency는 5.324ms; 목표는 20ms 이하입니다.
- Peak RSS는 202.44MB입니다. 결과: SLO PASS.
DB List
db_list
정렬과 light projection이 포함된 paginated document list입니다. Raw storage benchmark가 아니라 실제 list API workload에 가까운 항목입니다.
- 5,268 RPS 측정; 목표는 최소 5,000 RPS입니다.
- p99 latency는 14.957ms; 목표는 20ms 이하입니다.
- Peak RSS는 202.73MB입니다. 결과: SLO PASS.
DB Relation
db_relation
Akan relation path와 batching 동작을 사용하는 document relation lookup입니다.
- 16,149 RPS 측정; 목표는 최소 1,500 RPS입니다.
- p99 latency는 5.228ms; 목표는 60ms 이하입니다.
- Peak RSS는 202.77MB입니다. 결과: SLO PASS.
익숙한 기준과의 비교
Minimal HTTP routing 기준에서 Akan Pure HTTP는 ElysiaJS, raw Bun.serve, Hono 같은 Bun 기반 minimal framework와 가까운 범위에 있습니다. 중요한 기준은 이것입니다. Akan은 higher-level API 기능을 사용하기 전 runtime 단계에서 큰 penalty를 치르지 않습니다.
Akan Signal API가 router-only framework보다 낮게 보이는 이유는 같은 양의 일을 측정하지 않기 때문입니다. Minimal router benchmark는 보통 요청을 받고 응답을 반환하는 경로만 측정합니다. 반면 Signal API는 Akan의 API lifecycle, middleware와 guard 지점, request argument 처리, response shaping, 그리고 load balancing에 쓰이는 gateway-to-worker 경로까지 포함합니다. 같은 기능을 minimal router에 middleware나 plugin으로 추가하면 그쪽도 추가 overhead를 지불하게 됩니다.
그래서 33,845 RPS와 p99 3ms 미만이라는 결과는 단순 ping보다 application-facing 수치로 더 의미가 있습니다. Akan의 higher-level API 경로가 일반적인 no-DB endpoint에 충분한 여유를 가진다는 뜻입니다.
Document list API에서 raw bun:sqlite는 storage ceiling입니다. SQLite가 row를 얼마나 빨리 반환할 수 있는지만 보는 수치입니다. Akan DB List는 의도적으로 더 많은 일을 합니다. SQLite 위에 document API 형태, 정렬, pagination, light projection, document materialization, response serialization, Signal response 처리를 추가합니다.
이 overhead가 문제가 되지 않는 이유는 측정 경로가 실제 list endpoint가 필요로 하는 동작에 더 가깝기 때문입니다. 5,268 RPS와 p99 14.957ms로 현재 list API SLO를 통과하므로 framework 비용은 보이지만 실용 범위 안에 있습니다.
이 정도면 충분히 빠른가?
Routing 위에 full-stack convention을 포함하는 framework라는 점을 고려하면 이 결과는 실용적입니다. Pure HTTP 경로는 Bun minimal router와 경쟁 가능한 범위에 있고, Signal API는 SLO 대비 명확한 여유가 있으며, document DB 경로도 latency와 throughput 목표 안에 들어옵니다.
요약하면, 이 로컬 벤치마크 기준에서 Akan.js 2.0.7은 일반적인 API 중심 application에 충분히 빠릅니다. Router-level 성능은 빠른 Bun 생태계에 가깝고, higher-level Akan API도 실용적인 service target을 통과합니다.