Ran_Chat 프로젝트 성능최적화

TPS, Latency 측정 및 최적화 방법 선정

---

1. 회원 참여 채팅방 리스트 조회 API

• 회원이 참여하고 있는 채팅방 목록을 조회하는 API (정렬 포함)

WHY?

1. 해당 API는 사용자의 채팅방 리스트를 조회하는 내용으로 호출이 빈번할 것으로 예상된다.
2. 또한 캐싱을 사용하지 않기에 반드시 부하테스를 수행해야한다. (물론 실제로직은 매 호출하지 않고 , optimistic update를 사용하고 있다.)

API 명세서 : https://rand-chat.gitbook.io/rand_chat-docs/i-o/i-o-api/undefined

• 병목 발생지점 파악 및 케이스 파악

  • 사용 툴 : JMETER

    CASE 1 : Threads : 100 , Loop Count : 2 - > ERROR : 0 %
    CASE 2 : Threads : 200 , Loop Count : 2 - > ERROR : 0 %
    CASE 3 : Threads : 300 , Loop Count : 2 - > ERROR : 0 %
    CASE 4 : Threads : 400 , Loop Count : 2 - > ERROR : 52.12%
    -> NGINX 502 : 느린 응답시간때문에 타임아웃이 발생한것으로 판단됌.
    
    
    CASE 3 , 4 에 대한 정확한 TPS 및 Latency 재측정

    CASE 3 X 3회수행

    

  • TPS : 6.2

  • Average Latency : 35485

  • Min Latency : 1589

  • Max Latency : 50215

    
    

    CASE 4 X 1회수행

    

  • TPS : 6.6 (에러로 인한 비정확한 수치)

  • Average Latency : 44967

  • Min Latency : 23

  • Max Latency : 120028

  • ERROR: 49.62 %
    
    
    보다시피 에러관점에서 보면 초기 요청은 잘 처리하나 뒤로 갈수록 지연응답으로 인해 처리가 늦어지는 것으로 보인다. 이에 따라 CASE 4 에서는 NGINX 타임아웃이 발생하여 에러를 뱉고있다.

    성능관점에서 보면 TPS 6정도의 수치는 매우 좋지않은 수치로 보여진다. 이는 100명의 사용자가 동시에 요청을 한다고 치면 94명은 기다려야 한다는 말이다.
    
    

따라서 해당 API는 쿼리튜닝을 통해 I/O응답을 개선하고 , 그 후에도 문제발생 시 스케일업이나 스케일 아웃을 통해 성능개선을 진행한다.

2. 채팅메시지 리스트 조회 (오래된 메시지 조회) API

• 채팅메시지 리스트 조회 API (이전 메시지 조회)

WHY?

1. 해당 API는 채팅방의 채팅메시지 리스트를 조회하므로 , 핵심기능이라 볼 수 있다.
2. 물론 1페이지는 Redis에 캐싱이 되어있지만, 캐시미스 시 1페이지를 조회하며, 오래된 메시지를 보려면 해당API를 호출해야한다.

API 명세서 : https://rand-chat.gitbook.io/rand_chat-docs/i-o/i-o-api/undefined-3

• 병목 발생지점 파악 및 케이스 파악

• 사용 툴 : JMETER

  CASE 1 : Threads : 300 , Loop Count : 2 - > ERROR : 0 %
  CASE 2 : Threads : 500 , Loop Count : 2 - > ERROR : 0 %
  CASE 3 : Threads : 700 , Loop Count : 2 - > ERROR : 1.79 %
  CASE 4 : Threads : 1000 , Loop Count : 2 - > ERROR : 22.40%
  -> EC2 메모리와 스레드부족 현상으로 판단됌
  
  
  CASE 3 , 4 에 대한 정확한 TPS 및 Latency 재측정

  CASE 3 수행

  

• TPS : 369.1

• Average Latency : 756

• Min Latency : 0

• Max Latency : 2377

• ERROR : 1.79%

  
  

  CASE 4 수행

  

• TPS : 501.4 (에러로 인한 비정확한 수치)

• Average Latency : 659

• Min Latency : 0

• Max Latency : 2250

• ERROR: 21.40 %
  
  

  해당 API는 TPS와 Latency는 무난하게 나오고 있다고 생각한다.

  하지만 ERROR가 발생하는 이유는 아무래도 프리티어의 EC2를 사용하다보니 클라우드 서비스 성능이슈라고 생각이된다.

  정확한 원인은 분석을 해봐야 알겠지만 , 현재로서는 Min Latency가 0인점 , Average Latency가 무난한 수치인점 , TPS도 무난한 점을 고려해봤을때 , 로드밸런싱을 담당하는 NGINX 서버의 백로그큐(대기큐)가 가득차 연결을 맺지 못하는게 아닐까 싶다.
  
  

따라서 해당API는 NGINX서버의 스케일업을 진행해보고 해당 문제가 아닐 시 chat-io 서버의 문제라 인식한 후 Latency개선 및 스케일아웃을 고려한다.