[ 230827 ] 37주차 회고

일주일 간 진행한 내용

 

1. 입찰 API 성능 테스트
3. 입찰 API 성능 개선

 

 

---

입찰 API 성능 테스트

 

[진행]

입찰 API 성능 테스트를 진행했다. EC2 Instance t2.micro 서버로 Jmeter를 통해 요청을 보냈다. 먼저 SSE를 연결을 했다. SSE 연결이 완료되는 것을 확인하고 입찰 API를 1,000건씩 늘리며 보냈다. 이후 Jmeter의 결과에 대한 정보와 netdata에 기록되는 CPU, Memory 정보를 저장했다. 그걸 서버에서 에러가 날 때까지 계속해서 진행했다. 그리고 여기에 대한 결과를 가지고 팀원과 이야기를 하며 어떤 방향으로 나아갈지 정했다.

 

[생각]

입찰 API 성능 테스트를 해보는 것은 어렵지 않았다. 하지만 거기에서 만나는 여러 가지 에러들이 나를 힘들게 했다. 서버에서만 에러가 터지는 것이 아니라 Jmeter에서도 에러가 터지고는 했기 때문이다. 이것으로 시간이 너무 많이 소요가 되었기 때문이다. 프로젝트에 남은 시간이 많지 않은 것 같은데 해보고 싶은 것들은 많아서 생기는 힘듦이었다. 그래도 이것을 그냥 넘길 수는 없어서.. 참 아쉽다. 내가 조금 더 경험치가 있었더라면 좋았을 텐데.. 말이다.

 

 

 

---

입찰 API 성능 개선

 

[진행]

입찰 API를 하다 보니 서버에서 에러가 터졌다. 에러를 확인하다 보니 Connection Pool로 인해서 생기는 문제라는 것을 알았다. 그래서 Connection Pool에 대해서 알아보았다. 알아보고 나니 비관적 락을 걸어두었던 Transaction 때문에 병목 현상이 발생한다는 것을 알았다. 그래서 이걸 해결하기 위해 조사를 했다. 로직을 개선해 Transaction 시간을 줄이는 방법, Connection Timeout 짧게 주는 방법, Connection Pool의 크기를 늘려주는 방법, Scale-Up을 해서 컴퓨터의 성능을 향상해 주는 방법들이 있었다. 팀원과 협의를 해서 먼저 해볼 수 있는 것들을 적용해 보기로 했다.

 

[생각]

성능을 개선해 볼 수 있다는 것은 색다른 느낌이었다. 개선하기 위해 원인을 찾아보는 과정 또한 즐거웠다. 원인에 대한 해결 방법을 알아보고 그것을 적용했을 때 개선되는 것을 보았을 때 내가 무언가를 해냈구나 하는 것도 있었다. Scale-Up을 적용했을 때 개선된 입찰 API 성능을 보였고 거기에 로직 개선으로 성능 개선이 더 되었다. 이것을 통해 남은 개선 방안들을 적용했을 때 어떤 성능 향상이 보일지 기대가 되기도 했다. 그리고 하나의 API도 성능 개선할 사항들이 많은데 다른 것들은 그러지 않을까 하는 생각도 들면서 기회가 되면 해보고 싶다는 마음도 들었다.