인프런의 '백엔드 애플리케이션 성능 테스트하기'를 보면서 내용을 정리한다.
성능 테스트는 어떤 상황에서 왜 하는가?
일반 사용자에게 서비스를 오픈했을 때 서비스가 대박이 났다면?
트래픽이 폭주할 것이다.
이에 서버의 부하가 증가할 것이다.
이 트래픽을 감당하려면 얼마나 많은 서버가 있어야 할까?
(물론, 모든 트래픽을 감당하기 위해서 서버를 무한대로 증설할 수는 없다.)
성능 테스트는 사용자가 많아졌을 때를 가정해서 연습해볼 수 있게 도와준다.
성능 테스트 툴로 트래픽을 생성 --> 요청수를 계산해서 서버가 얼마나 필요할지 계산
추가록, 비효율적인 로직을 개선(메모리 정리가 안돼서 자꾸 GC가 발생하는 등)
성능 테스트를 위한 배경 지식
지연시간(Latency)와 처리량(Throughput)
지연시간은 요청 한 건 한건의 처리 시간을 말한다.
클라이언트 입장에서는 api를 호출하고 응답이 와야 그 다음 작업을 수행할 수 있다.
사용자가 체감하는 중요한 성능 지표다.
처리량은 단위 시간동안 얼마나 많은 작업을 처리할 수 있는지에 대한 지표다.
일 초에 몇 건? 이런 느낌
- cf) 대역폭 :네트워트가 단위시간동안 보낼 수 있는 데이터 양
성능을 측정할 때는 지연시간과 처리량을 모두 측정해야 한다.
일반적으로 처리량이 낮으면 지연시간도 낮다. 처리량이 많아질수록 지연시간도 함께 늘어나게 된다.
운영체제와 서버 자원
- 운영체제는 서버의 물리적 자원을 관리하면서 필요한 곳에 자원을 할당해서 애플리케이션을 실행시킨다.
프로그램을 시작하면, 이 프로그램은 메모리 위에 올라온다. 이걸 프로세스라고 부른다.
- 프로세스 = 메모리+코드
cpu는 프로세스에 정의된 코드를 실행한다.
네트워크
이러한 네트워크 통신은 많은 자원을 사용한다.
거리가 멀어질수록 시간이 더 오래 걸림
대역폭을 넘어서면 그만큼 전송 시간이 늦어짐
데이터베이스
데이터베이스도 일종의 애플리케이션이다. 운영체제가 실행하는 프로그램.
- db 지연시간이 길어질 때
-짧은 시간동안 많은 요청이 들어올 때
-얼마나 많은 데이터가 db에 저장돼있는지도 중요한 요소
-응답 데이터가 클 때 (100mb 데이터를 응답으로 줄 때)
-트랜잭션을 지원하기 위한 락이 필요 이상으로 많이 걸릴 때
- HDD? SSD?
SDD가 용량은 작고 비싸지만 HDD보다 속도가 훨씬 빠르다.
디스크가 느리면 CPU와 메모리도 이에 맞춰서 느려짐
성능이 정말 중요한 DB라면 SSD를 쓸 수 있음. 다만 비싸다.
둘 사이의 데이터를 동기화(갱신)이 중요하다. 네트워크 회선의 대역폭도 커야 함. 오가는 데이터도 많음. 다른 서버에 영향을 줄 수 있어서,
이 둘만 사용하는 전용회선을 붙이면 좀 더 빨라짐
스레드 풀과 커넥션 풀
- 데드락이 발생하면... 대기가 생겨서 스레드 풀이나 커넥션풀처럼 제한된 수량으로 생성되는 것들이 낭비됨
모든 스레드가 사용되는 상황이면 일부 요청이 큐에 저장됨. 큐가 꽉차면 요청이 버려짐
그렇다고 해서 스레드를 무작정 늘리면 서버자원이 이를 감당하지 못함
커넥션풀도 마찬가지임
성능 테스트의 방향성
- 실무에서의 성능 테스트
-많은 처리량을 감당할 수 있는 인프라를 구축할 수 있음
-
실무가 아닌 경우
-한건씩 요청을 봰서 지연시간이 어느정도 나오는지 확인한다.
-처리량을 점점 높이면서 현재 인프라 구성에서 지연시간이 치솟는 지점이 어딘지 찾아보기
-어떤 부분이 병목이 되는지 가설을 세워보고, 서버 자원 모니터링/로그 등을 통해 병목 지점 탐색
-병목을 해결하는 방법을 적용
