문제 데이터의 로딩이 느리다는 문제를 해결하기 위해서 메소드 성능 측정을 위한 AOP를 추가했습니다.
QuestionService 클래스의 findByType 메소드의 성능 측정을 위해 TimerAop 클래스를 추가하고,
@Timer 어노테이션을 findByType 메소드에 추가했습니다.
(기존에 Timer 인터페이스는 존재했었습니다)
로컬에서 이 메소드의 성능 측정 시 처음 로딩할 때는 0.2초, 이후 로딩 때는 0.02초 정도 걸리는 것으로 확인되었습니다.
-> 단, 로컬에서는 문제 데이터 수가 적기 때문에, 배포해서 테스트해보아야 제대로 테스트 될 것으로 생각했습니다.
가설 수립
서버에서 로딩이 지연되는 이유는 2가지 정도 원인으로 분석했습니다.
(1) 문제들을 로딩할 때, 로그인한 사용자가 푼 문제인지를 확인하기 위해, Answer 테이블에 추가적인 쿼리를 보냅니다.
-> 이 쿼리의 성능이 좋지 않기 때문에 로딩이 지연될 수 있다고 판단했습니다.
(2) 현재 프론트와 서버가 AWS의 다른 Region에 있는 다른 인스턴스에 배포 되어 있습니다.
-> 이로 인해 프론트에서 서버로 요청을 하고 응답을 받는데에 시간이 오래 걸리게 되었을 수 있다고 판단했습니다.
추가 계획
(1) 우선, 현재 코드를 배포하고, 배포된 버전에서 메소드의 성능 측정을 해봐야 할 것으로 생각했습니다.
-> 만약, 메소드의 성능이 좋지 않다면, 쿼리에 대한 수정이 필요할 것입니다.
(2) 그 다음 메소드의 성능에 문제가 없다면, 프론트의 배포 인스턴스를 서버와 동일한 인스턴스로 교체하는
작업을 진행해볼 예정입니다 .
문제 정의 및 실행한 작업
문제 데이터의 로딩이 느리다는 문제를 해결하기 위해서 메소드 성능 측정을 위한 AOP를 추가했습니다.
QuestionService 클래스의 findByType 메소드의 성능 측정을 위해 TimerAop 클래스를 추가하고, @Timer 어노테이션을 findByType 메소드에 추가했습니다. (기존에 Timer 인터페이스는 존재했었습니다)
로컬에서 이 메소드의 성능 측정 시 처음 로딩할 때는 0.2초, 이후 로딩 때는 0.02초 정도 걸리는 것으로 확인되었습니다. -> 단, 로컬에서는 문제 데이터 수가 적기 때문에, 배포해서 테스트해보아야 제대로 테스트 될 것으로 생각했습니다.
가설 수립
추가 계획
(1) 우선, 현재 코드를 배포하고, 배포된 버전에서 메소드의 성능 측정을 해봐야 할 것으로 생각했습니다. -> 만약, 메소드의 성능이 좋지 않다면, 쿼리에 대한 수정이 필요할 것입니다.
(2) 그 다음 메소드의 성능에 문제가 없다면, 프론트의 배포 인스턴스를 서버와 동일한 인스턴스로 교체하는 작업을 진행해볼 예정입니다 .