개발잡부

일단 삽질 부터 정리를 하자면.. 왜 삽질을 정리하냐 물어보신다면.. "결과가 좋지 않으니 시간낭비를 하지 말자" 라는 의미로 첨에 성능개선의 방향을 메소드 별 캐싱, 즉 동적인 결과를 반환하는 메소드 외에 검색키워드에만 영향을 받아 캐싱이 되어도 무방한 정적인 데이터를 처리하는 메소드를 캐싱 해버린다. 이렇게 캐싱할 메소드를 정해놓고 데이터 처리 하는 로직을 component 에 이관하고 component 를 캐싱하려고 했으나.. 메소드 캐싱을 할수록 시간이 증가하는 기적이 .. 20~50ms 씩 증가.. 위의 구조라면 저것들을 다 캐싱하는 순간.. 그래서 캐싱은 1번으로 끝내고 가능하다면 최전방으로 배치한다. 의 전략 최초 호출인 /search 의 호출을 캐싱해버리는.. /search 호출은 상품정보..

Concept 실제 서비스에 적용될 api cache 의 구성 동적인 데이터를 처리하는 메소드와 정적인 데이터를 처리하는 메소드를 구분하여 캐싱 구성 Detail Data component 데이터를 조회 / 후처리 까지 처리하는 메소드 Data component 단위로 캐싱 application.yml 더보기 spring: profiles: local redis: timeout: 1000 lettuce: pool: max-active: 3 max-idle: 3 min-idle: 3 password: password elasticache: master: - name: itemList redisMaster: host: 127.0.0.1 port: port - name: itemSpecial redisMast..

Api 성능이슈로 정적인 데이터, 동적인데이터에 분리가 필요하고 정적인 데이터에 대한 캐싱이 필요한 상황이 되었다. cache 키를 어떻게 생성할건지에 대한 고민을.. 우선 키 생성방법은 단일 param 을 key 로 cache key 생성 @Cacheable(value = CacheKey.DISTANCE, key = "#request.distance", unless = "#result == null") 복수의 param 을 key 로 cache key 생성 @Cacheable(value = CacheKey.DISTANCE, key = "{#request.distance, #request.countryCode}", unless = "#result == null") key generator 를 만들어서 ..

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

검색결과중 일부 메소드에서 처리하는 데이터 들만 캐싱해야하는 상황.. 일단 구현해보자 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..

지난시간 elasticsearch 의 file system cache 를 사용해서 성능을 올려보았는데 https://father-lys.tistory.com/40 [java] API - file system cache (request cache) API 를 만들고 응답시간을 측정해서 최적의 성능을 만들어 보자 일단 제물이 될 index 820만건의 location-index 일단 aqqle 의 shop API 를 응용해서 후다닥 만들어 보자. 복붙해서 이름만 바꾸니까 1분 미 father-lys.tistory.com 캐싱하면 redis 니까 함 넣어보잣 우선 redis 설치 https://father-lys.tistory.com/41 그리고 aqqle api 에 redis 설정 1. build.gradl..

API 를 만들고 응답시간을 측정해서 최적의 성능을 만들어 보자 일단 제물이 될 index 820만건의 location-index 일단 aqqle 의 shop API 를 응용해서 후다닥 만들어 보자. 복붙해서 이름만 바꾸니까 1분 미만 컷 지금은 bool > filter > term 쿼리로 조회하니 응답속도가 빠르다. 일단 이 상태에서 리소스 사용과 응답속도를 측정해보잣 캐싱이 안되고 있지만 너무 빠르다 일단 지난 캐시 테스트와 같은 구조로 multi_match 쿼리 와 count집계(aggs) 를 두번 추가 전체쿼리 더보기 { "size":100, "query":{ "bool":{ "must":[ { "multi_match":{ "query":"country_code", "fields":[ "CO^1...

망할 스웨거 Cannot invoke "org.springframework.web.servlet.mvc.condition.PatternsRequestCondition.toString()" 원인은 spring boot 2.6.0부터 요청 경로를 ControllerHandler에 매칭시키기 위한 전략의 기본값이 ant_path_matcher 전략 -> path_pattern_parser 전략으로 변경되었기 때문 일단 해결 방법 spring: mvc: pathmatch: matching-strategy: ant_path_matcher 2.5.x 이하로 버전을 낮추라고 하는데 낮춰도 안됨 // https://mvnrepository.com/artifact/io.springfox/springfox-swagger2..

Java의 CompletableFuture에서 get()과 join() 메소드는 모두 완료된 CompletableFuture의 결과를 반환 get() join() interrupt O X interrupt 발생 InterruptedException 인터럽트 차단 Exception ExecutionException UncheckedExecutionException get() 메소드는 java.util.concurrent.Future 인터페이스에 정의되어 있으므로 이 인터페이스를 구현하는 다른 클래스와 호환 가능하지만, join() 메소드는 CompletableFuture 클래스에만 특화되어 있기 때문에 CompletableFuture와만 사용할 수 있다 일반적으로 CompletableFuture을 다룰 때..

class file major version 61은 로드 하려고 시도하고 있는 클래스 파일이 자바 17 혹은 그 이상의 버전에서 컴파일이 되었으며, 자바 17 이상에서만 사용 될 수 있을 때 발생 class file major version 63 은 자바 19 왜 이 사단이 났는지 부터 파악해 보자면.. intelliJ 업데이트가 불러온 참사이다. 매년 10만원 넘게 주고 결제하는 중인데 이왕이면 최신버전으로 써야지 했다가.. gradle 버전이 바뀌고 내장되어 있는 jackson 플러그인 버전이 바뀌면서 저런 버전 문제가 뜨기 시작함 jdk 버전만 올려도 안될경우 gradle 버전도 같이 올려야 한다 라는 교훈을 얻었지만 역시 업데이트는 신중하게..