REVIEW - 박정국 CTO가 알려주는 ‘서버 성능 측정 방법’

 

해당 블로그는 아래 링크의 영상을 참고하여 제작하였습니다.

 

https://www.youtube.com/watch?v=HSNyJnobBws 

 

 

 

API 서버 성능 이해하기

 

측정 조건

- 많은 사람들이 사용해도 API 응답 시간이 짧고 안정적이다.

- 많은 사람, 응답시간 안정적의 기준은?

- 10명이 동시에 호출시 1초안에 모두가 응답받음 vs 100명이 동시에 호출시 10초안에 모두가 응답 받음

 

 

측정 지표

-> 제한속도를 높일것이냐 도로를 넓힐 것이냐

- Latency : 요청자의 입장에서 완료까지 걸리는 가, 예시 : 속도가 빠른 차량

- Throughput : 작업자의 입장에서 시간당 얼마나 처리하는 가, 예시 : 넓은 도로

 

 

측정 방법

-> 서버에 많은 사람이 접속할 수록 더 느려짐은 상식적으로 참이다 이를 전제로 아래와 같이 측정 가능

- 서버가 초당 처리 가능한 요청 수

(서버의 한계치를 할 수는 있지만 동시 접속자에 대한 지표가 되지 못함)

- 서버가 초당 처리 가능한 요청 수를 설정 후 얼마나 사용자들이 쾌적하게 사용가능한가를 측정

(예시, 100명의 유저가 30초 동안 인당 한번씩 요청을 보낸다. 이 때 응답시간은?)

 

 

 

 

서버 성능 개선 방법

 

1. 서버 대수를 늘린다.

- 서버마다 폭을 늘리는 개념

- 어떤 서버를 늘리는가? 프록시 서버 vs WAS vs DB 서버

- 기본적으로 DB, 프록시는 상용 서버이기에 성능이 우수, WAS의 폭을 늘린다.

- 서버 폭을 고려해 서버를 늘린다. WAS 폭 늘려 WAS가 DB 서버보다 우수시 DB 서버를 늘리는 방식

 

2. 코드를 효율화 한다.

- 요청을 처리하는 시간을 고려한다. 이 때, 기본적인 처리 속도는 프록시 서버 > DB > WAS 순이라고 볼 수 있음.

- WAS의 코드를 효율적으로 작성해(알고리즘, 효율적인 쿼리) 요청에 대한 처리 속도를 줄인다.

- DB는 인덱스나 denormalization을 통해 처리속도 향상

 

 

 

 

결론

1. 서버 성능을 나타내는 지표는 다양하며, 정답이 없다

2. 성능 측정시 "몇 명의 사용자가 어느 정도의 밀도로 API를 요청할 때 서버의 응답속도 분포는~ "의 형태가 현실적이다.

3. 서버의 성능은 상황에 따라 scale-out하거나 코드를 효율화 하는 방법이 있다.