[MSG-Lab] 우테코 따라잡기 1차 답안지

문제지

 

해설

1. ide 대신 콘솔로 실행하기

인텔리제이로 실행하게 되면, 불필요한 java agent가 함께 실행된다.

콘솔 커맨드로 실행하여 오버헤드를 줄였다.

 

2. jvm 설정

jvm 메모리 사이즈를 설정하지 않으면, 낮은 수치부터 힙을 살살 늘린다.

힙을 실행시점에 할당하여 오버헤드를 줄였다.

Xmx, Xms 둘 다 같은 수치로 설정하면 정적으로 할당한다.

 

3. jvm warm-up

if kakao 2022를 참고했다.

직접 c2의 lv4까지 컴파일된 로그를 확인했다.

처음에는 약 천줄만 c2 lv4였다면, warm-up 이후에는 4천줄가량이 카운팅되었다.

warm-up 전 c2 lv4의 갯수

warm-up 후 c2 lv4의 갯수

총 컴파일된 코드 수

 

4. tomcat 튜닝

인스턴스에 적합한 tomcat 설정을 찾았다.

쓰레드가 너무 많으면 컨텍스트 스위칭 비용이 커진다.

시작시 쓰레드수가 너무 적으면 이걸 생성하는 비용이 크다.

 

5. jpa oisv 설정

connection acuire 시간이 점점 높아지는걸 확인했다.

우려할 수준은 아니지만, Rest api에서 osiv 설정은 필요 없어 false로 세팅했다.

이후 connection acuire 시간이 감소함을 확인했다.

 

어플리케이션 실행시 oisv 설정을 fals로 수정하라는 경고 문구를 확인했다.

실제로 테스트시 connection acquire 시간이 너무 길었다.

이는 connection이 불필요하게 길게 유지되기 때문이었다.

따라서 oisv를 false로 설정하여 해결했다.

spring에서 제공하는 osiv는 기존의 osiv와는 다른점이 있다.

기존에는 정말 트랜잭션이 뷰레이어까지 유지가 되었다. 즉 컨트롤러에서 엔티티를 수정하면, 디비 데이터를 건드리게 된다.(transaction per request 방식)

하지만 스프링에서는 트랜잭션이 비즈니스 계층에서만 시작한다.(컨트롤러에서 엔티티를 수정하고 서비스 시작하면 디비 데이터가 수정된다는 말이다...)

덕분에 뷰 레이어에서 디비를 건드릴 걱정 없이 osiv를 사용할 수 있다고 한다.

그래도 우리 프로젝트에서는 json으로 클라이언트에게 데이터를 서빙해서 osiv 설정이 필요없다.(지연로딩같은 기능이 애초에 필요 없다.)

결과적으로 osiv 설정이 어플리케이션에 주는 영향은 미미하다는걸 알게 되었다.

원래는 트랜잭션이 불필요하게 길게 유지된다고 생각했지만, 스프링 osiv는 이를 해결했기 때문이다.

그래도 실행시 출력되는 경고 문구와 여전히 우리에게 필요하지 않은 뷰 레이어의 영속 컨텍스트를 제거하기 위해 osiv설정은 disable 했다.

 

6. spring-retry

테스트중 절대 에러가 있어서는 안된다.

하지만 간헐적으로 FCM api 자체에서 fail이 있었다.

fail 시 재요청 로직을 구현하여 해당 문제를 해결햇다.

 

7. jmeter time-out 설정

재요청 로직에서 backoff 시간을 설정했다.

한번 실패하면 1초 간격으로 3번 재요청을 한다.

따라서 최소 3초는 기다려야한다.

하지만 재요청중 jmeter에서 connection을 닫아버리는 문제가 있었다.

jmeter 타임아웃 시간을 6초로 늘려 해결했다.

 

결과

latency

TPS

평균 3초안에 응답을 내려주었다.

TPS는 초당 95정도이다.