아빠는 개발자

검색성능 개선 final 이다. 지금까지 테스트 해본 결과를 바탕으로 구조를 잡아서 테스트 ( final 이라고 해놓고 진격의 거인마냥 final part 1, final part 2, final 1기 1쿨 이렇게 증식되지 않기를 바랄뿐..) 우선 이슈는 픽업 서비스 오픈 이후 response time이 튀는 현상이 발생했다. 당연히 검색쿼리로 데이터 조회 후 처리 로직이 추가되었으니 당연히 응답시간이 늘어나는건데 이것이 문제가 되고 있으니.. 늘어난 응답시간은 100ms 이하라서 사용자가 인지하기 힘든 속도이긴 하나. cloud watch 의 모니터링 대시보드에선 널뛰기를 하는 모습으로 나온다. 그래도 로직이 추가될때마다 성능이 저하된다면 문제가 맞긴 한듯하다 cloud watch의 ALB 대상그룹의 ..

메소드 별로 redis 케시를 태워서 검색 성능을 최적화 해보자 Cache Api 에서 multi_match 쿼리 1 회, multi_match 쿼리 + Aggs 3회 를 실행한다. file system cache : 적용 redis cache : 미적용 API 평균 : 58.97 API 평균 : 58.28 API 평균 : 58.19 Cache Api 에서 multi_match 쿼리 1 회, multi_match 쿼리 + Aggs 3회 를 실행한다. 여기서 Aggs 처리하는 메소드에 redis cache 를 적용하고 cache key 는 country code 로 한다. file system cache : 적용 redis cache : 적용 API 평균 : 61.48 API 평균 : 13.01 API 평..

검색결과중 일부 메소드에서 처리하는 데이터 들만 캐싱해야하는 상황.. 일단 구현해보자 https://father-lys.tistory.com/42 에서 세팅한 redis 정보를 활용 우선 컨드롤러 생성 CacheService 의 getCaches 를 호출 package com.doo.aqqle.controller; import com.doo.aqqle.model.CommonResult; import com.doo.aqqle.service.CacheService; import io.swagger.annotations.Api; import io.swagger.annotations.ApiOperation; import io.swagger.annotations.ApiParam; import lombok.Requ..