본문으로 건너뛰기

병목 분석

TODO — 재측정 대기 중

이전 분석은 현재 삭제된 benchmark/results/* 산출물(bottleneck-analysis.md, internal-stage-toggle-comparison.md)을 사용했습니다. 당시 측정에서는 GIL 환경에서 spawn_blocking_delay와 event_loop_resume_delay가 가장 큰 비용을 차지했습니다. Production Benchmark → Python 3.14t에는 이 결과와 함께 free-threaded Python에서 두 stage가 거의 0으로 줄어드는 과정이 남아 있습니다.

아직 필요한 작업은 새 Isolated Benchmark harness(s1–s5, oha, Podman, 로컬 Aerospike CE 8.1.2.1_3)에서 stage별 결과를 다시 측정하는 것입니다. Harness는 AEROSPIKE_PY_INTERNAL_METRICS=1을 통해 db_client_internal_stage_seconds histogram을 이미 지원합니다. 하지만 전체 matrix를 실행하고 결과를 문서로 정리하는 작업은 끝나지 않았습니다.

추적 항목:

  • Isolated 하네스에서 stage profiling 매트릭스 재측정 (s1 / s3 / s4_gather × py3.11 GIL × py3.14t free-threaded)
  • s4_gather vs s4_single 에서 gather(N) → single batch_read(mixed keys) recipe 재검증
  • 새 측정값 반영 후 stage profiling 활성화 표면 (env var · 런타임 토글 · scoped context manager) 정리

재측정 시 다룰 내용​

  1. stage 별 breakdown — batch_read 의 stage 이름 (key_parse, limiter_wait, tokio_schedule_delay, io, into_pyobject, spawn_blocking_delay, event_loop_resume_delay, to_dict, to_numpy, merge_to_dict, future_into_py_setup) 별 latency 분포.
  2. stage profiling 활성화 방법 — AEROSPIKE_PY_INTERNAL_METRICS=1 env var, aerospike_py.set_internal_stage_metrics_enabled(True) 런타임 토글, scoped context manager. 세 가지 모두 현재 존재; 비활성 시 오버헤드는 stage entry 당 AtomicBool 로드 1회 수준.
  3. 유의미한 최적화 recipe. 이전 round 의 우승자: (a) aerospike-py 로 교체, (b) gather(N batch_reads) 를 단일 batch_read(mixed keys) 로 통합, (c) Python 3.14t free-threaded 로 전환. (a) 와 (c) 는 Isolated Benchmark 와 Production Benchmark 에 이미 정량화되어 있고, (b) 는 s4_gather vs s4_single 에서 재측정 예정.

새 측정이 나오기 전까지는 Production Benchmark의 3.14t stage breakdown을 각 단계의 비용을 설명하는 기준 자료로 사용하세요.