Apex Core

SPSC vs MPSC 큐 비교가 이번 v0.5.10.0의 핵심이다. SPSC(wait-free)는 1P1C 시나리오에서 MPSC(lock-free) 대비 일관되게 빠르다. CAS 루프가 없는 wait-free 구현이 단일 생산자-소비자 경로에서 성능 우위를 가져온다.

N코어 환경에서 N×(N-1) SPSC mesh는 단일 MPSC 대비 경합 없는 전용 채널을 제공하여, 코어 수 증가에 따른 선형 확장이 가능한 아키텍처. MPSC의 2P1C 시나리오에서 발생하는 CAS 경합이 SPSC mesh에서는 원천 차단된다.

커스텀 할당기 3종이 모두 시스템 할당기보다 10배 이상 빠르다. BumpAllocator가 7~10ns로 가장 빠르며(monotonic 할당, 개별 dealloc 없음), SlabAllocator가 10~11ns(alloc+dealloc 쌍), ArenaAllocator가 15~20ns(블록 체이닝 오버헤드).

malloc은 120ns, make_shared는 154ns로 커스텀 할당기 대비 10~20배 느리다. make_shared의 추가 비용은 atomic ref-count 초기화와 control block 할당. Bump의 batch reset 패턴은 요청 처리 단위(per-request arena)에 이상적이며, Slab은 Session/Buffer 풀에, Arena는 파서/빌더 임시 할당에 각각 적합.

FrameCodec의 Encode/Decode 처리량은 페이로드 크기에 비례하여 증가한다. 64B 소형 메시지에서는 고정 비용(헤더 직렬화, CRC 계산)이 지배적이며, 16KB 대형 메시지에서 Encode 26.9 GB/s, Decode 22.6 GB/s를 달성한다.

Encode가 Decode보다 일관되게 빠른 이유: Decode 시 헤더 파싱 + 무결성 검증 오버헤드. 실 서비스에서 평균 메시지 크기(~512B)에서 Encode 7.2 GB/s, Decode 4.3 GB/s로, 10Gbps NIC 대역폭을 충분히 활용 가능.

FlatBuffers vs new+memcpy 빌드 성능 비교. HeapAlloc이 빌드 시 2~2.5배 빠르다 — 64B 기준 HeapAlloc 98ns vs FlatBuffers 243ns. FlatBuffers의 빌드 오버헤드는 vtable 구성, 필드 정렬, builder 내부 버퍼 관리 때문이다.

그러나 FlatBuffers의 핵심 장점은 읽기 측 zero-copy 역직렬화이다. 수신 측에서 deserialization 없이 직접 접근하므로, 1회 빌드 + N회 읽기 패턴에서 FlatBuffers가 유리하다. 서버 프레임워크에서 라우팅/디스패치 경로는 읽기 빈도가 압도적이므로 FlatBuffers 선택이 올바르다.

boost::unordered_flat_map이 대규모 순회에서 std::unordered_map 대비 2.5배 빠르다 — 10K 세션 iterate: flat_map 26ms vs std 66ms.

flat_map은 open addressing 방식으로 데이터가 연속된 메모리에 저장되어 CPU 캐시 히트율이 높다. 반면 std::unordered_map은 node-based(포인터 체이닝)라 캐시 미스가 빈번하다. 조회(find)는 둘 다 O(1)로 비슷하지만, 전체 세션 순회(브로드캐스트, 상태 점검 등)에서 캐시 지역성 차이가 극적으로 드러난다.

Apex Core는 SessionManager, MessageDispatcher, CrossCoreDispatcher, KafkaHandlerMap 등 4곳에서 flat_map을 사용하며, 특히 SessionManager의 세션 전체 순회 시 이 성능 차이가 실질적 영향을 미친다.

intrusive_ptr vs shared_ptr: SessionPtr(intrusive_ptr) 복사가 6.3ns로 shared_ptr 18ns 대비 2.9배 빠르다. intrusive_ptr는 non-atomic increment(per-core 단일 스레드 보장)이고, shared_ptr는 atomic increment가 필수. 세션 참조가 핫패스에서 빈번하므로 intrusive_ptr 선택이 성능에 크게 기여.

TimingWheel은 O(1) 타임아웃 관리로, 1K 배치에서 27M items/s를 처리. Session Create는 443µs로 TCP 소켓+버퍼 초기화를 포함하지만, 커넥션 수립 시 1회만 발생하므로 핫패스 영향 없음.

zero-copy RingBuffer vs naive memcpy: RingBuffer가 모든 크기에서 2.5~4.5배 빠르다. 64B: RingBuffer 35ns vs naive 156ns, 4KB: 103ns vs 251ns.

naive 방식은 매번 힙 할당+해제(new/delete)가 추가되므로 오버헤드가 크다. RingBuffer는 미리 할당된 순환 버퍼에서 포인터만 이동하므로 할당 비용 제로. Linearize(래핑 경계 처리)에서도 31~44ns로 naive 대비 빠르며, 대부분의 경우 contiguous read로 memcpy 없이 직접 접근.

7개 방법론 비교 핵심 수치:
① SPSC vs MPSC — wait-free가 lock-free보다 빠름
② 커스텀 할당기 vs malloc — Bump 7ns, Slab 11ns, Arena 20ns vs malloc 120ns (10~17x)
③ flat_map vs std::unordered_map — 대규모 순회에서 flat_map 2.5x 빠름 (캐시 지역성)
④ intrusive_ptr vs shared_ptr — 2.9x (non-atomic vs atomic refcount)
⑤ zero-copy vs naive — 2.5~4.5x (RingBuffer vs new+memcpy)
⑥ FrameCodec 스케일링 — 페이로드 비례 처리량 증가
⑦ FlatBuffers vs heap — 빌드 2.5x 느리나 읽기는 19~32x 빠름 (zero-copy 역직렬화)

이 섹션은 Apex Core 프레임워크의 실전 성능을 end-to-end로 검증한다. 개별 컴포넌트 벤치마크가 '부품의 성능'을 측정한다면, 통합 벤치마크는 '조립된 엔진의 성능'을 보여준다.

코어 간 통신 (Cross-core RTT ~17µs): SPSC mesh를 통한 코어 0↔코어 1 ping-pong 왕복 지연. 이 수치에는 io_context::post() 비용, SPSC 큐 enqueue/dequeue, 코루틴 재개, 스레드 스케줄링이 모두 포함된다. 순수 SPSC 큐 연산(~10ns)과의 차이가 곧 프레임워크 오버헤드이며, 이는 ~17µs 중 대부분이 OS 스레드 스케줄링과 io_context 이벤트 루프 비용임을 의미한다.

Frame Pipeline (6~7µs/msg, 4KB 기준 0.6 GB/s): 클라이언트 메시지가 서버에 도착하여 처리되기까지의 전체 경로 — WireHeader 파싱 → RingBuffer 프레임 추출 → FlatBuffers 역직렬화 → MessageDispatcher 핸들러 조회 → 핸들러 실행. 각 단계가 나노초 수준이므로 전체 파이프라인도 마이크로초 수준에서 완료된다.

Session Echo (8~9µs/msg, 4KB 기준 444 MB/s): TCP 소켓 I/O를 포함한 진정한 end-to-end. Pipeline 대비 느린 이유는 TCP loopback 소켓 전송/수신 비용이 추가되기 때문이며, 이것이 실 서비스에서 I/O가 CPU 처리보다 지배적인 병목임을 증명한다. 프레임워크의 CPU-side 처리는 이미 충분히 빨라서, 성능 향상의 다음 레버는 I/O 최적화(io_uring, DPDK 등)에 있다.

Apex Core의 per-core 아키텍처(shared-nothing)는 이 모든 단계에서 lock-free 경로를 보장한다. 코어 간 통신만 SPSC 큐를 거치고, 나머지 모든 처리는 해당 코어의 전용 io_context에서 단일 스레드로 실행되므로 mutex 없이 동작한다. 워커 수가 증가하면 처리량이 선형으로 확장되는 구조이며, 이는 전통적인 단일 io_context + 스레드 풀 모델의 lock contention 문제를 원천 회피한다.

아키텍처 비교 — Per-core vs Shared io_context: 현실적 서버 워크로드(세션 맵 조회 + 상태 읽기/수정)에서 Per-core 아키텍처의 선형 확장성을 검증했다. 각 핸들러는 unordered_map에서 세션을 조회하고 상태를 읽고 수정하는 — 실제 서비스에서 매 메시지마다 수행하는 작업을 시뮬레이션한다.

핵심 결과 — Per-core는 워커 수에 비례하여 처리량이 선형 증가하고, Shared는 최적화해도 정체된다:

• 1워커: Per-core 0.51M vs Shared 0.53M — 동일 (경합 없는 기준선)
• 2워커: Per-core 0.90M vs Shared 0.64M — 1.4배 ⚡
• 3워커: Per-core 1.24M vs Shared 0.72M — 1.7배 ⚡
• 4워커: Per-core 1.56M vs Shared 0.74M — 2.1배 ⚡

Per-core의 자체 확장률이 선형에 근접한다: 1워커 대비 2워커 1.76x, 3워커 2.43x, 4워커 3.06x — 77~88% 효율로 이상적 선형 확장에 근접한다.

Per-core 선형 확장의 원리: 각 워커가 자기 세션 맵을 소유하고 독립된 io_context에서 post + run을 실행한다. 워커 간 공유 상태가 없으므로 lock이 불필요하고 캐시 라인 경합도 발생하지 않는다. 워커를 추가할 때마다 처리량이 순증한다.

Shared 모델은 최적화해도 정체된다: Shared 측에는 64-shard 파티셔닝을 적용하여 세션 맵 mutex 경합을 최소화했다 — 이는 전통적 서버 아키텍처에서 숙련된 엔지니어가 적용하는 표준 최적화이다. 그러나 처리량은 여전히 0.77M에서 정체된다. 원인: 세션 맵 lock을 샤딩해도, 단일 io_context의 내부 핸들러 큐 경합이 근본적 병목으로 남기 때문이다.

결론 — 이것이 Per-core 아키텍처를 채용한 근본적 이유이다: 락 최적화(샤딩, reader-writer lock 등)만으로는 한계가 있고, io_context 자체를 워커별로 분리해야 진정한 선형 확장이 가능하다.

※ 테스트 PC는 4물리 코어(i5-9300H) 기준입니다. 물리 코어가 더 많은 프로덕션 서버에서는 4워커 이상에서도 선형 확장이 유지됩니다.