[java] API - 검색 api 성능 개선 final

검색성능 개선 final 이다.

지금까지 테스트 해본 결과를 바탕으로 구조를 잡아서 테스트

( final 이라고 해놓고 진격의 거인마냥 final part 1, final part 2, final 1기 1쿨 이렇게 증식되지 않기를 바랄뿐..)

 

우선 이슈는 픽업 서비스 오픈 이후 response time이 튀는 현상이 발생했다. 

당연히 검색쿼리로 데이터 조회 후 처리 로직이 추가되었으니 당연히 응답시간이 늘어나는건데 이것이 문제가 되고 있으니..

늘어난 응답시간은 100ms 이하라서 사용자가 인지하기 힘든 속도이긴 하나. cloud watch 의 모니터링 대시보드에선 널뛰기를 하는 모습으로 나온다. 그래도 로직이 추가될때마다 성능이 저하된다면 문제가 맞긴 한듯하다

 

cloud watch의 ALB 대상그룹의 지표를 확인해보니 검색되는 document 의 사이즈가 달라 후처리 속도의 차이가 나고 그래서 들쭉날쭉 하는 모습으로 로깅되는 듯..

 

우선 생각한 구조는 정적인 데이터와 동적인 데이터로 나눠야 캐싱의 대상을 정할 수 있을것으로 판단.. 아래와 같은 구조로 

지난번  4개 메소드 실행  후 2개의 메소드를 추가하여 실행 

#기본
cacheCompo.getCacheName(countryCode)
cacheCompo.getCacheFilter(countryCode)
cacheCompo.getCacheAttr(countryCode)
cacheCompo.getCacheAggs(countryCode)

#추가
cacheCompo.getCacheAvg(countryCode)
cacheCompo.getCacheSum(countryCode)

Case 1. 전체 캐싱하지 않음 

API 평균 : 80.12	API 평균 : 75.03	API 평균 : 75.75

 

Case 2. 전체 캐싱

API 평균 : 65.77	API 평균 : 10.33	API 평균 : 10.38

 

Case 3. match query 메소드 캐싱안함, aggs 메소드 1개 캐싱안함 - 2개 캐싱, 2개 캐싱 안함 

API 평균 : 70.34	API 평균 : 66.77	API 평균 : 68.13

음.. 뭔가 이상하다. 

캐시의 사이즈가 1/3 수준으로 줄어들줄 알았는데... 

Aggs 쿼리를 다 같은걸로 테스트를해서 그런가 캐싱안함과 이렇게 차이가 안나나.. 아무래도 이 final version 은 2기 1쿨이 생길 것 같다. 

 

API 평균 : 174.61	API 평균 : 171.98	API 평균 : 175.06

이랄줄 알앗다..

request cache 가 aggs 이름으로 생성되는데 코드를 복사해서 집계쿼리를 타는것에만 신경쓰다보니 aggs 이름이 중복되는 것을 간과하고 테스트를 하다니..  request cache 의 사이즈는 250정도에서 800 까지 올라가고 응답시간 또한 평균 2배이상 올라갔다. 

 

다시 2개의 메소드를 캐싱하고 테스트 

전체 4개의 메소드에서 multi_match query 실행하는 메소드와 aggs 메소드 1개를 제외한  나머지는 redis 캐싱

request cache 의 사이즈는 최초 쿼리에서는 redis 에 캐싱이 되지 않았기 때문에 800까지 올라가지만 2개의 메소드가 캐싱된 후 

250정도 (약 1/3) 캐시사이즈를 유지하고 응답속도도 빨라졌다.

API 평균 : 173.42	API 평균 : 66.32	API 평균 : 65.94

 

4개의 메소드에서 2개의 aggr 메소드를 캐싱 한 상태에서 2개 메소드 추가 추가된 2개의 메소드도 캐싱을 태워본다.   

API 평균 : 280.59	API 평균 : 68.15	API 평균 : 68.3

첫번째 테스트에서는 1300 정도의 request cache 사이즈를 사용하지만 두번째 시도에서는 4개의 메소드가 캐싱되어 있기 때문에 4개중 2개의 메소드만 캐싱했을때보단 조금크지만 비슷한 크기의 캐시 사이즈를 사용하고 있다. 

 

2개의 non caching 메소드만 실행 

4개중 2개만 non caching 으로 실행했을때와 6개중 2개만 non caching 으로 실행했을때와 큰차이는 없지만 캐시생성 되기전엔 큰 차이를 보인다. 

API 평균 : 63.55	API 평균 : 63.85	API 평균 : 63.78

결론

1. query 구조는 ES 레벨에서 캐시를 사용할 수 있는 구조로 쿼리를 작성/사용한다. 
2. 데이터를 정적, 동적 데이터로 구분하고 정적인 데이터는 redis cache 를 이용해 캐싱한다. 
3. 새로 추가되는 기능들 또한 최대한 캐싱이 가능한 구조로 설계

 

하는데.. 그게 가능하려나?