RustConf에서 나온 Tokio 성능 원칙 정리: poll 10~100마이크로초, schedule latency가 핵심 지표

Tokio 성능 튜닝은 개선하려는 실제 지표에서 거꾸로 출발해야 함. 거의 모든 실제 앱의 poll이 Alice Ryhl이 권장한 10~100마이크로초보다 길지만, 사용자 지표에 영향이 없으면 고쳐도 측정 가능한 변화가 없음
지연 시간에는 분할, 처리량에는 배치. 연결 사이 공정성을 위해 더 자주 yield하고, 오버헤드 상쇄를 위해 작업을 묶는 것이 기본 원칙이며 그 외에 전역 자원 경계, 뮤텍스 주의, 병렬성 제한, 워커 스레드 격리를 다룸
가장 유용한 런타임 지표는 최근 추가된 schedule latency 히스토그램. 작업이 실행 가능해진 시점과 Tokio가 실제로 future를 poll한 시점 사이의 시간으로, 원인은 알려주지 않지만 Tokio와 앱 코드가 어긋날 때 가장 흔한 증상
예외 기법으로 실행자 블로킹이 괜찮은 경우, 우선순위별 워크로드 분리를 위한 다중 런타임 사용, 제어권 유지를 위한 스핀을 소개. 작성자 Russell은 RustConf Unconf 논의를 바탕으로 한 초안이며 샘플 앱을 추가할 예정이라고 밝힘

Hacker News 의견들

에이전트 코딩으로 세밀한 트레이싱 계측 붙이기가 진짜 쉬워졌더라. 이런 최적화에 딱임

그러다 앱 시간 대부분을 관측 오버헤드에 쓰게 됨. 글에서 언급한 latency 히스토그램도 겁나 비쌈

내가 본 서버 앱 전부 같은 문제였음. CPU 시간 대부분을 epoll 들어갔다 나오고 자기 작업 훔치는 메타 작업에 씀. 원칙은 다 좋은데 지키기가 너무 쉬움

Axum이 Tokio 위에서 100개 넘는 스택 트레이스 뽑는 거 보고 놀랄 일은 아님. tokio-rs 조직 아래 프로젝트인데도 그럼

Tokio 튜닝할 단계면 ef_vi/DPDK랑 SPDK도 봐봐

그거 참고자료 있음? Tokio랑 같이 쓰는 게 아니라 Tokio를 대체하는 쪽 같던데

진짜 고성능 원하면 스레드 busy-spin, CPU pinning, SPSC/MPSC 링 버퍼 써야 함

다 케이스 바이 케이스임. 나는 실시간 요구가 빡센 임베디드 하는데 CPU pinning은 선택지도 아님. 고성능의 의미가 다 다르더라

뮤텍스 조심하라는 건 좋은데 Tokio가 제공하는 채널을 대안으로 언급 안 한 게 의외임. 내가 본 뮤텍스 병목 절반은 뮤텍스 자체를 안 쓰고 채널로 필요한 데이터만 넘겼으면 피했을 것