빠른 Tokio 애플리케이션을 위한 원칙

Tokio 성능은 공정성과 배치 처리, 경합과 격리의 균형에 달려 있으며, 같은 작업도 런타임에서 함께 실행되는 작업에 따라 성능이 달라짐 최적화는 긴 폴링 자체를 없애기보다 실제 개선할 지표에서 출발해야 함. 실행 준비부터 실제 폴링까지 걸리는 스케줄링 지연은 Tokio와 애플리케이션 코드의 상호작용 문제를 찾는 유용한 신호임 낮은 지연시간에는 빈번한 실행권 양보, 높은 처리량에는 작업 배치 처리가 유리함. 지나치게 작은 태스크나 개별 블로킹 작업은 스케줄링과 조정 비용을 늘림 공유 자원 경합과 무제한 동시성을 경계해야 함. 블로킹 큐, 전역 태스크 큐, 경합하는 뮤텍스는 병목을 만들 수 있으며, 짧은 임계 구역과 동시성 제한이 필요함 Tokio 워커를 다른 스레드와 격리하면 운영체제 스케줄링으로 인한 지연을 줄일 수 있음. 다중 런타임, 긴 폴링 허용, 짧은 스핀 대기는 워크로드와 부하 조건을 따져 적용해야 함 실제 문제와 지표부터 확인하기 Tokio 성능에는 일률적으로 적용할 규칙이 적음. 다른 작업과의 상호작용 때문에 프로덕션에서만 문제가 드러나기도 함 실제 애플리케이션에는 Alice Ryhl의 What is Blocking?이 권하는 10~100마이크로초보다 긴 폴링이 흔하지만, 사용자 지표에 영향을 주지 않는 긴 폴링을 고쳐도 측정 가능한 개선은 없을 수 있음 경험상 문제 대부분은 Tokio 자체보다 애플리케이션 코드, 특히 분산 시스템 구성 요소 간 상호작용에 있었음 dial9는 Tokio 내부를 관찰하는 데 쓰이며, Tokio 문제가 없음을 확인해 다른 곳을 조사할 근거를 주기도 함 물론 Tokio 자체가 원인인 경우도 있음 최근 추가된 스케줄링 지연 히스토그램은 특히 유용한 런타임 지표임 소켓에 데이터가 도착하는 등의 이유로 태스크가 실행 준비된 시점부터 Tokio가 실제로 퓨처를 폴링할 때까지의 시간을 측정함 원인을 직접 알려주지는 않지만, 스케줄링 지연은 Tokio와 코드의 상호작용이 좋지 않을 때 가장 흔히 나타나는 증상임 지연시간을 줄이려면 실행권을 나누기 여러 요청의 지연시간을 낮추려면 연결 간 공정성이 필요함 Redis처럼 요청 파이프라이닝을 지원하는 애플리케이션은 버퍼에 쌓인 요청을 연속 처리하며 워커를 오래 점유할 수 있음 파이프라인의 전체 또는 대부분이 메모리 버퍼에 들어오면 프레임 읽기가 네트워크로 돌아가지 않고 계속 Poll::Ready를 반환함 한 클라이언트의 파이프라인 전...