본문으로 건너뛰기

성능 개요

이 문서는 aerospike-py(Rust, PyO3, native async)와 공식 aerospike Python client(C extension을 loop.run_in_executor로 실행)를 비교합니다.

TL;DR — DLRM 서빙 p95 누적 효과

324 ms → 97 ms (−70%) — 세 단계 누적: 클라이언트 교체 → batch_read 통합 → Python 3.14t.

p95 누적 효과​

원본 (공식 client, 3.11 GIL, gather)            ████████████████████████  324 ms   baseline
+ aerospike-py 로 교체                          ██████████████             189 ms   −42%
+ gather(N) → 단일 batch_read(mixed keys)       █████████                  126 ms   −61%
+ Python 3.14t free-threaded                    ███████                     97 ms   −70%  🔥
                                                                           ↑ 3.3× 빠름

환경: FastAPI + DLRM + Aerospike CE, k6 10 VUs × 60s, replica 2개 (4 CPU / 4 GiB request).

권장 조치 (순서)​

#조치p95 효과
1공식 client → aerospike-py 교체−42% (Python 3.11)
2gather(N) → 단일 batch_read(mixed keys)−33% 추가 (GIL 환경)
3런타임을 Python 3.14t free-threaded 로 전환−49% 추가, TPS +47%
4AEROSPIKE_PY_INTERNAL_METRICS=1 상시 ONE2E 오버헤드 ≈ 0

환경별 격차 (Python 3.11 + GIL)​

Application stack이 단순할수록 client 자체의 차이가 크게 보입니다. 실제 serving workload에서도 비율은 줄지만 tail latency의 이점은 유지됩니다.

HTTP 요청부터 batch_read, DLRM CPU inference, 응답까지 전체 경로를 측정합니다. 실제 recommendation serving pod와 가장 비슷한 환경입니다.

지표aerospike-py공식aerospike-py 우위
avg118 ms146 ms−19%
p90173 ms293 ms−41%
p95189 ms324 ms−42% 🔥

→ 상세 (Production Benchmark, env C)

문서 구성​

페이지언제 읽나
Isolated Benchmark"client 라이브러리 자체가 격차에서 얼마나 차지하나?" — 5 시나리오 (s1..s5) 를 로컬 podman/oha 하네스로 측정, 응답 직렬화 비용 제거. 시나리오마다 materialisation 경로 하나만 격리 (dict / to_numpy zero-copy / gather vs single / lazy subset). 3.14t 섹션 포함.
Production Benchmark"실 서빙 pod 가 보는 값은?" — FastAPI + DLRM + Aerospike CE on k8s, k6 부하, response body 직렬화 포함, replica 2개. 324→189→97 ms 누적 효과 스토리. 3.14t 섹션 포함.
Bottleneck AnalysisStage profiling 및 recipe (gather→single 등). 새 isolated 하네스 기반으로 재측정 진행 중.

로컬 재현은 benchmark/README.md 참조.