- 전체보기(115)
- git(4)
- elasticsearch(4)
- github(4)
- 스프링(3)
- 자바(3)
- rabbitmq(2)
- Cache(2)
- K6(2)
- mysql(2)
- stomp(2)
- transactional(2)
- Flask(2)
- REST API(2)
- JWT(2)
- Index(2)
- 채팅(2)
- JPA(2)
- 토큰(2)
- redis(2)
- SpringSecurity(2)
- API(2)
- 스프링부트(2)
- 정적 웹 서버(1)
- Restful(1)
- rds(1)
- 3계층구조(1)
- kibana(1)
- REST(1)
- ResponseEntity(1)
- back(1)
- DAO(1)
- 웹 서비스 발전(1)
- 세션(1)
- 쿠키(1)
- 엔티티(1)
- 준영속 엔티티(1)
- 웹 소켓(1)
- BASIC 인증(1)
- 모델(1)
- 컨트롤러 레이어(1)
- 브라우저(1)
- 인덱스(1)
- 서블릿 엔진(1)
- 검색엔진(1)
- Read(1)
- MPA(1)
- aws ec2(1)
- 어노테이션(1)
- wsgi(1)
- message broker(1)
- 병합(1)
- 도메인 모델 패턴(1)
- gradle(1)
- ResponseDTO(1)
- 비동기(1)
- 병렬성(1)
- class(1)
- entity(1)
- 레이어드 아키텍쳐(1)
- RestController(1)
- front(1)
- 서블릿(1)
- CREATE(1)
- 멀티 스레드(1)
- 서블릿 필터(1)
- https(1)
- Nginx(1)
- json(1)
- WAS(1)
- 동의어 사전(1)
- 멀티 프로세스(1)
- 서비스 레이어(1)
- 비동기 큐 작업(1)
- 트랜잭션(1)
- 서블릿 컨테이너(1)
- delete(1)
- String(1)
- StringBuffer(1)
- @GenerateValue(1)
- cascade(1)
- update(1)
- CSS(1)
- 동적 웹 서버(1)
- 파싱(1)
- React 컴포넌트(1)
- html(1)
- RequestBody(1)
- CSR(1)
- SSR(1)
- 렌더링(1)
- 2계층구조(1)
- Logstash(1)
- celery(1)
- gunicorn(1)
- spa(1)
- 멀티 코어(1)
- Cotroller(1)
- 자바 컬렉션(1)
- Web Server(1)
- JSX(1)
- @RequestParam(1)
- Swagger(1)
- VO(1)
- 퍼시스턴스 레이어(1)
- PersistenceContext(1)
- 지연로딩(1)
- 트랜잭션 스크립트 패턴(1)
- 엔티티 직접 사용(1)
- 동시성(1)
- 변경 감지(1)
- StringTokenizer(1)
- kakao(1)
- DTO(1)
- Stateless(1)
- Message Queue(1)
- 즉시로딩(1)
- DispatcherServlet(1)
- 스프링 시큐리티(1)
- 로그인(1)
- 폼 객체(1)
- cors(1)
- 자바 제네릭(1)
- sql(1)
- 동기(1)
- Beats(1)
- @PathVariable(1)
진짜진짜 간단한 쿼리 개선을 해보았다.
문제 발생 제가 작성한 이전 게시물에서 잘못된 생각으로 글을 작성한 것을 깨달았습니다. 깨닫게 되고 데이터를 조회하는 쿼리를 진짜진짜 간단히 쿼리 개선 해보게 되었습니다. 우선 전체 상품 데이터를 조회하는 getproductall_list 함수를 봐보겠습니다. 이 함수에서 이 코드는 Flask 내부의 Pagination을 적용한 것으로, 데이터베이스에는 어떠한 WHERE 조건을 사용하여 쿼리를 날리지 않습니다. paginate 메소드는 페이지네이션을 수행하며, 데이터베이스에서 현재 페이지의 데이터만을 추출합니다. 즉, 데이터베이스는 페이지별로 필요한 데이터만을 가져옵니다. _**저
상품 검색 성능 테스트
글을 쓰기 앞서... 성능 테스트 글을 쓸 수 있게 끔 도움을 주신 Whatap Laps의 김기현 개발자님에게 진심으로 감사합니다. 지금껏 습득한 지식을 정리를 하거나 좋은 내용을 가져다 쓴 경우가 많았는데 저 스스로 무언가를 해보고 고민을 해보고 글을 쓸 수 있었습니다. 데이터베이스에는 50만 데이터가 있습니다. 상품 검색 API의 latency를 줄이고 Vus를 늘리게된 성능개선을, k6를 통해 확인한 기록일지입니다. k6로 부하테스트를 쓴 이유와 각 테스트의 목적에 대해서는 이전글([전체 데이터 조회 성능 테스트 기록](https://velog.io/@junsu1222/%EC%A0%84%EC%B2%B4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A1%B0%ED%9A%8C-%EC%84%B1%EB%8A%A5-%ED%85%8C%EC%8A%