내 사이드 프로젝트 코드는 Http Request 를 여러 고루틴으로 요청하여
결과값을 파일로 저장한다.
고루틴은 이런 상황에 정말 효율적일까?
Network IO 측면
효율적이다. Http 요청을 처리하는 웹 서버가
서로 다른 서버로 총 10개의 요청을 보냈다고하자.
어느 서버는 빠르게 응답하고, 어느 서버는 늦게 응답할 것이다.
응답을 기다리는 고루틴들은 대기(Waiting) 상태가 되고
Go runtime Scheduler 가 다른 Logical Run Queue 에 존재하는 다른 Runanble goroutine 을 실행(executing) 상태로 전환하여 실행시킬 것이다.
File I/O 측면
효율적이다.
실제 File IO 는 go 프로세스 코드가 아니라 OS Kernel 의 시스템 콜 함수가 실행한다.
goroutine 은, File IO 이벤트 발생시 대기(Waiting) 상태가 되고 OS에서 파일 쓰기를 실행할 것이다.
대기 상태에 들어가면 Logical Process 는 Logical Run Queue 의 Runanble 상태인 다른 고루틴을 실행시켜 다른 작업을 실행한다.
대기 상태였던 고루틴은 파일 쓰기가 완료된 시점에 OS kenrel 로 부터 SIGNAL 을 받아 다시 Runnable 상태가되어 Local Run Queue 에 들어간다.
CPU 측면
GO scheduler 에 의해 당장 CPU 의 점유를 받지 않는 고루틴에 대해 Runnable, Waiting 상태로 관리하고 GOMAXPROCS 갯수만큼 적정수의 goroutine 을 병렬로 실행(executing)하여 CPU 사용 효율을 극대화한다.
그래도, Context switching 비용이 발생하잖아요?
맞다. 그러나 Goroutine 은 초기에 매우 작은 크기의 스택을 할당받는다. (겨우 2KB부터 시작한다.)
멀티 쓰레드의 Context Switching 에 비하면 비용도 매우 작다.
결론
고루틴은 다수 HTTP 요청에 효율적이다.
그렇다고 무조건 성능 향상이 이뤄지는건 아니다. 파일 쓰기만해도 운영체제에 따라, HDD냐 SSD냐 , RAM 사양, CPU 에 따라 효용이 없을 수도 있다.
그러나 서버 전용으로 나온 일정 수준 이상의 사양의 인스턴스에선 효과를 볼 수 있을것이다.
