본문으로 건너뛰기

운영 환경 벤치마크

이 end-to-end benchmark는 production 형태의 deployment를 사용합니다. uvicorn 위의 FastAPI, request path의 DLRM CPU inference, Aerospike CE, k6 HTTP load, serialize된 response body를 모두 포함합니다.

HTTP parsing, JSON serialization, model forward pass처럼 recommendation serving pod가 부담하는 비용이 모두 측정됩니다. 공통 비용 때문에 Isolated Benchmark보다 client 간 차이는 작게 보이지만, capacity planning에는 이 수치가 더 적합합니다.

Sources: 2026년 4월에 내부에서 측정했습니다. Raw 산출물은 저장소에 commit하지 않았으며, benchmark/를 다시 작성하기 전 git history의 benchmark/results/*.md에서 확인할 수 있습니다. 아래 주요 수치는 해당 산출물에서 가져왔습니다. 새 isolated harness에서 다시 측정하는 작업은 Bottleneck Analysis에서 추적합니다.

격차가 어디 있는가​

Mean latency advantage of aerospike-py vs official (Python 3.11 + GIL)

A) Pure DB client       ████████████████████  −80%  (108 → 22 ms)    🔥
B) uvicorn ASGI         █████                 −21%  (290 → 228 ms)
C) uvicorn + DLRM       ███████████           −42% p95 (324→189 ms)  🔥

mean 차이가 줄어도 Environment C에서는 p95 우위가 유지됨: 공식 client의 result 변환이 tail에서 GIL 때문에 직렬화됨.

Environment A — Pure DB Client​

측정 범위. FastAPI, model inference, HTTP load generator를 제외합니다. Python loop가 batch_read를 직접 호출하므로 client 자체의 차이가 가장 크게 나타납니다.

Setup​

ItemValue
Source2026년 4월 내부 run (pre-rewrite artifact; git history 에서 복원 가능)
Clientsofficial (sync C), official-async (executor 로 sync 래핑), py-async (aerospike-py)
Sets / batch sizes9 / 50, 200
Concurrency / iterations10 / 30

Aggregate 결과 (9 sets × 2 batch sizes 평균)​

Clientavg mean (ms)avg p99 (ms)avg TPS
official107.56195.34138.2
official-async110.64211.33125.7
py-async (aerospike-py)22.45120.67373.7
py-async vs officiallatency 4.8× 빠름1.6×TPS 2.7× 높음
py-async vs official-async4.9× 빠름1.8×3.0×

Per-set speedup 분포 (aerospike-py vs official)​

Batch 50:   mean speedup across 9 sets   4.4× ──────── 7.8×    (median ~5.8×)
Batch 200:  mean speedup across 9 sets   3.1× ──────── 6.6×    (median ~4.5×)

Outlier: set_8 (0% found rate) → fast not-found path, 실 read latency 아님.
set_8 은 outlier

Found rate가 0%입니다. 공식 client는 success path보다 error를 빨리 반환하므로 이 row는 실제 read latency가 아니라 빠른 not-found path를 보여 줍니다. 나머지 모든 set에서는 mean latency가 4~8배 개선되었습니다.

**official-async**는 sync C client를 loop.run_in_executor로 실행합니다. Request마다 thread pool을 거치므로 모든 set에서 bare sync client보다 조금 느립니다. 따라서 aerospike-py와 official-async의 차이는 official과의 차이보다 일관되게 큽니다.

환경별 패턴​

   layer 가 추가될수록 →        ratio 압축,            tail 은 여전히 우위
   ─────────────────             ──────────             ──────────────────
A) Pure DB (HTTP/ML 없음)        mean 4.8×              p99 1.6×
B) uvicorn ASGI                  mean 1.27×             ≈ noise at C=5
C) uvicorn + DLRM                mean 1.24×             p95 −42%  🔥

Database call 주변에 layer를 추가하면 mean ratio는 4.8×에서 1.24×로 줄어듭니다. 그러나 upper-percentile 우위는 유지됩니다. aerospike-py는 I/O 중에 GIL을 해제하지만 공식 client는 run_in_executor를 거치며 GIL 획득이 직렬화되어 tail latency가 커집니다.

Python 3.14t free-threaded — 같은 pipeline, GIL 제거​

Python 3.14t는 GIL을 비활성화한 free-threaded CPython 빌드(Py_GIL_DISABLED=1)입니다. 아래 수치는 같은 Environment C pipeline(FastAPI + DLRM + k6 10 VUs × 60s)에서 runtime만 바꿔 측정했습니다. Rust와 C source는 변경하지 않았습니다.

TL;DR​

p95 single-mode (k6 10 VUs × 60s, FastAPI + DLRM)

aerospike-py
  3.11 + GIL    ███████████████              189 ms
  3.14t         ████████                      97 ms   −49% 🔥

official (C extension)
  3.11 + GIL    █████████████████████████    324 ms
  3.14t         ██████████                   128 ms   −60% 🔥

Throughput (aerospike-py): 41.6 → 61.2 iter/s   +47%

GIL은 두 client 모두의 병목이었습니다. aerospike-py는 Rust 코드를 바꾸지 않고도 성능이 개선되었습니다.

무엇이 빨라지는가 (그리고 왜)​

부하를 준 상태에서 측정한 internal stage timing입니다. GIL의 영향을 받는 두 stage가 거의 0으로 줄었습니다.

Stage                     3.11 + GIL              3.14t       Change
────────────────────────────────────────────────────────────────────
spawn_blocking_delay      234 ms     ████████    0.12 ms      −99.95% 🔥
event_loop_resume_delay   39.7 ms    ██           ≈ 0         ≈ −100%
io (Aerospike network)    7.51 ms    ▌           1.27 ms      −83%
merge_to_dict             4.48 ms    ▎           3.54 ms      −21%
key_parse                 967 μs     ·           1.06 ms      +10% (noise)
tokio_schedule_delay      83.1 μs                49.5 μs      −40%
limiter_wait              3.56 μs                0.96 μs      −73%

개선 폭의 대부분은 다음 두 stage에서 나옵니다.

  • **spawn_blocking_delay**는 234 ms에서 0.12 ms로 줄었습니다. GIL 환경에서는 Rust async future가 끝난 뒤 결과를 Py<...> 객체로 바꾸는 작업을 spawn_blocking worker에 전달합니다. Worker는 GIL을 얻어야 하므로 asyncio event loop와 다른 worker가 경합하면 queue 대기가 수백 ms까지 늘어납니다. GIL이 없으면 worker가 바로 실행됩니다.
  • **event_loop_resume_delay**는 거의 0으로 줄었습니다. GIL 환경에서는 future가 끝나 event loop가 깨어난 뒤에도 coroutine이 GIL을 얻을 때까지 기다립니다. Free-threaded mode에서는 여러 coroutine을 병렬로 재개할 수 있습니다.

io가 8배 줄어든 것은 간접 효과입니다. Tokio worker가 Python 코드와 GIL을 두고 경쟁하지 않고 Aerospike protocol response를 parse할 수 있게 되었습니다.

3.14t 의 same-workload 비교​

Python 3.14t에서 두 client에 같은 server load를 적용했습니다. 같은 pod 안의 endpoint를 k6 10 VU가 번갈아 호출했습니다.

Clientp95 (single mode)Difference
aerospike-py126 msbaseline
official aerospike128 ms+2 ms (~1.5%, noise)

Python 3.11 + GIL에서 42%였던 차이가 Python 3.14t에서는 약 2 ms로 줄었습니다.

이는 client 구조보다 GIL 경합이 기존 차이의 대부분을 만들었다는 점을 보여 줍니다.

Throughput (TPS)​

3.11 + GIL, stage OFF             ████████████        41.6  baseline
3.11 + GIL, stage ON              █████████████       44.1  +6% (noise)
3.14t, aerospike-py only          ███████████████████ 61.2  +47% 🔥
3.14t, both clients (split load)  ██████████████      47.3  +14%
Configiterations/shttp_reqs/s
3.11 + GIL, stage OFF41.650.8
3.11 + GIL, stage ON44.152.9
3.14t, aerospike-py only61.280.0
3.14t, both clients (split load)47.359.8

그래도 solo load 에선 aerospike-py 가 여전히 우위 (3.14t)​

126 ms와 128 ms가 나온 측정에서는 10 VU가 두 endpoint로 나뉘어 각 client가 약 5 effective VU만 처리했습니다. 부하를 한 client에 집중하면 차이가 다시 커집니다.

Metricaerospike-py soloofficial soloaerospike-py 우위
k6 single p9597 ms134 ms−28%
k6 gather p95 (9× fan-out)107 ms253 ms−58% 🔥
Server predict_duration_seconds p95100 ms138 ms−28%
Server batch_read_all p9564 ms67 ms−4%
이론 capacity (Little's Law: 10 VUs / p95)~103 req/s~75 req/s+37%

Python 3.14t의 solo load에서도 aerospike-py가 더 빠른 이유는 다음과 같습니다.

  1. Native async와 thread pool wrapper의 차이. GIL 경합이 없어도 run_in_executor는 request마다 thread pool 전환을 추가합니다. aerospike-py는 asyncio loop에서 직접 await합니다.
  2. Lazy dict conversion. batch_read()는 LazyBatchRecords handle을 반환합니다. Python dict는 caller가 .to_dict()를 호출할 때 만들어집니다. .to_numpy(dtype)는 GIL을 해제한 structured array 경로를 제공합니다.
  3. FFI boundary를 한 번만 통과. aerospike-py의 Rust 코드는 PyO3 호출 한 번 안에서 전체 batch_read를 끝냅니다. C extension은 호출할 때마다 Python과 C의 경계를 여러 번 통과합니다.

Concurrency가 높아질수록 이 차이들이 누적됩니다. Gather 결과인 107 ms와 253 ms가 이를 가장 잘 보여 줍니다.

Migration notes​

  1. CI matrix에 Python 3.14t를 추가합니다. python:3.14.2t-slim에서 unit test와 integration test를 실행합니다.
  2. gil_used = false를 선언하기 전에 Rust의 unsafe와 shared mutable state를 점검합니다.
  3. 공식 client wheel을 기다리거나 직접 build합니다. PyPI에는 아직 공식 aerospike 패키지의 cp314t wheel이 없지만 source build는 동작합니다.

부수 효과: inference도 빨라집니다. Python 3.14t에서 control variable인 DLRM inference(PyTorch CPU)가 43.5 ms에서 20.7 ms로 52% 줄었습니다. 이 개선은 aerospike-py와 무관합니다. Async I/O와 함께 실행되는 GIL-bound inference path라면 같은 이점을 얻을 수 있습니다.

다음 단계:

  • Isolated Benchmark — FastAPI/JSON/inference 비용을 빼고 client 격차 자체 보기
  • Bottleneck Analysis — per-stage profiling, gather→single recipe (TODO: 새 harness 에서 재측정)