[TIL][C++] 250710 MMO 서버 개발 55일차: 응답 시간(response time)과 처리량(throuthput)은 다르다, 시스템콜 요청시 블로킹 함수, 논블로킹 함수일때 스레드는 코어에서 내려갈까?

주의사항: 해당 글은 일기와 같은 기록용으로, 다듬지 않은 날것 그대로인 글입니다. 

응답 시간(response time)과 처리량(throuthput)은 다르다.

• 서버 최적화를 하다 보면 응답 시간과 처리량을 고려하게 되는데, 비슷한 부분이 많아서 그런지 이 둘을 혼용해서 사용하는 경우가 있는 것 같다. 오늘은 각각의 개념과 예시를 알아볼 겸 정리해 보기로 했다.

 

처리량과 응답 시간이란?

• 처리량은 단위 시간당 처리한 데이터의 양을 의미한다.
• 응답 시간은 작업 요청 후 결과가 반환되기까지 걸리는 시간을 의미한다.

 

처리량 증가 = 응답 시간의 감소?

• 처리량이 증가하면 응답 시간이 증가 “할 수” 있다. 처리량이 높을수록, 각 요청에 대한 처리가 다른 요청에 밀리는 경우가 줄어들기 때문이다.
• 따라서, CPU가 구려 전체적인 처리량이 떨어진다면, 응답 속도는 떨어진다. 이 경우에는 하드웨어의 업그레이드(ex. 4 코어 → 8 코어)를 통해 응답 시간을 줄일 수 있다.
• 하지만 처리량 부족으로 인한 응답성 개선은 일정 수준 이상으로 향상하는 데에 한계가 있다.

 

예시 1) 100ms 내 응답이 만족스러운 게임인 경우

• 게임 서버 기준으로 100ms는 굉장히 긴 시간이다. 그럼에도 100ms안에 작업을 처리하지 못했다면, 이는 처리량 부족이 요인일 가능성이 높다.
• 따라서, 이 경우에는 처리량을 높였을 때 응답 속도의 향상을 기대할 수 있다.

 

예시 2) 1ms 정도의 응답 속도 차이에도 민감한 게임인 경우

• 예시 1과 반대되는 해당 경우는 어떨까? 이 경우에도 처리량을 높이면 반응성이 원하는 만큼 높아질까?
• 그렇지 않다. 1ms 정도 차이에도 민감해지는 경우가 되면 아무리 서버가 높은 처리량을 가지게 된다 하더라도 패킷이 오고 가는 시간(latency)이 훨씬 클 것이다. 즉, 물리적 서버의 위치를 변경하여 latency를 줄이는 것이 처리량 증가보다 응답 속도를 높이는데 더 많은 관련성이 있다는 것이다.

 

 

처리량과 응답 속도의 tradeoff 관계

• 이상적인 시스템은 높은 처리량과 짧은 응답 시간을 모두 제공하는 것이겠지만, 두 마리 토끼를 전부 잡을 수는 없는 상황이 많다. 왜냐하면 많은 경우에서 처리량을 희생시켜 응답 속도를 얻거나, 응답 속도를 희생시켜 처리량을 얻는, 즉, tradeoff 하기 때문이다.

 

 

처리량-응답 속도 tradeoff 예시들

1. 한 번에 모아서 처리하느냐, 올 때마다 처리하느냐 - 배치 처리 vs 즉시 처리
   • 배치 처리: 여러 작업을 한 번에 모아서 처리하는 방식. 각 작업을 처리하기 위해 일련의 프로세스를 모아서 처리함으로써 처리량이 높아지지만, 각 작업에 대기 시간이 발생하므로 응답 시간이 떨어진다.
   • 즉시 처리: 각 작업을 즉시 처리하기에 응답 속도가 빠르지만, 처리할 때마다 일련의 프로세스를 진행하므로 전체 처리량이 낮아진다.
2. 캐싱 전략
   • 작은 캐시: 빠른 접근으로 응답 시간은 빠르지만, 캐시 미스가 잦아 전체 처리량이 저하
   • 큰 캐시: 높은 적중률로 처리량은 좋지만 캐시 탐색 기간이 길어져 응답 시간 증가.
3. 공간 지역성
   • OS는 miss난 메모리를 가져올 때 그 주변 메모리를 동시에 가져온다. 이 현상에 의해 하나만 가져왔을 때 보다 작업량이 늘면서 응답 속도는 떨어지지만, locality 특성에 의해 cache hit 확률이 올라가며 처리량은 높아진다.
4. Nagle 알고리즘
   • Nagle 알고리즘은 일정 크기 이상으로 패킷들이 모였을 때 한 번에 전송하는 알고리즘이다. 문제는 이 알고리즘을 사용하는 순간, 맨 앞에 있는 패킷의 응답 시간이 200ms까지 올라갈 정도로 응답성이 떨어지게 된다.
   • 반면, Nagle 알고리즘은 비활성화하면 즉시 패킷을 보내기 때문에 응답 시간이 크게 내려가지만, 전송 횟수가 몇 배 이상으로 발생하기 때문에 전송에 의한 연산으로 전체적인 처리량은 떨어진다.

---

---

---

시스템콜 요청 시 블로킹 함수, 논블로킹 함수일 때 스레드는 코어에서 내려갈까?

 

블로킹 시스템콜은 그렇다.

• CPU 스케쥴러는 CPU 코어를 점유하고 있는 도중에 I/O 작업에 의한 블로킹이 발생하면 해당 스레드를 그대로 CPU 코어에서 내리고 다른 스레드를 점유시킨다. 그렇다면 블로킹 방식의 시스템콜은 전부 CPU 코어에서 내려버릴까?
• 그렇다. 봐주는 것 없이 똑같이 CPU 코어에서 해당 스레드를 내려버리는 것 같다.

 

논블로킹 시스템콜은?

• 논블로킹 시스템콜의 경우는 이야기가 다르다. 다른 논블로킹들이 그랬듯이, 논블로킹 방식의 시스템 콜을 호출해도, OS는 해당 스레드를 즉시 코어에서 내리지 않는다. 논블로킹 시스템 콜은 호출 즉시 반환되며, 작업 완료까지 기다리지 않고 다른 작업을 수행할 수 있게 한다.
• 논블로킹 시스템콜을 간접적으로 요청하는 WSARecv()와 WSASend()를 호출해도 CPU 코어에서 내려가지는 않는다는 것이다.