HikariCP의 정체는 무엇일까?
최근 포스트
SNUXI 개발일지 - 7 [최적화 수행 기록(수치화) - 2nd : 인터페이스 변경 / 레포지토리 함수 호출 최적화를 통한 쿼리 횟수 및 응답 시간 개선]
SNUXI 서비스에서, 페이지네이션 SQL 로그 관찰 및 API 성능 개선에 사용한 스크립트와 PromQL 쿼리, 데이터 수치화를 기록한다. 페이지네이션 API 쿼리 횟수 추적 및 개선 (1) 목표 RPS 계산: 유저당 최악의 경우 50회씩 페이지네이션 수행한다고 가정할 때, 총...
SNUXI 개발일지 - 6 [최적화 수행 기록(수치화) - 1st : 페이지네이션 인덱스 메모리 사용량 모니터링 및 기술 선택]
SNUXI 서비스에서, 페이지네이션 방식 테스트 및 서버 자원 사용량 모니터링 시 사용한 스크립트와 PromQL 쿼리, 데이터 수치화를 기록한다. 페이지네이션 방식 적합도 테스트 : 오프셋 vs 커서 문제 제시: 실제 서비스 환경에서, 무한 스크롤 기능을 지원할 때...
SNUXI 개발일지 - 5 [Lock 매커니즘 확인]
MySQL 연산시 어떠한 Lock이 동작하는지에 관해서는 이전에 총 정리한적 있다(next-key lock, gap lock, IX, IS, Redo/Undo 등등 최대한 많은 내용들을 이해하고 정리하였다). 아래 링크 참조 링크 : MySQL InnoDB의 동작 이를 바...
MySQL InnoDB의 동작 - 실제 장애 상황에서 InnoDB는 어떻게 동작할까? Durability
이 한 문장으로 전체 핵심을 말할 수 있을 듯 하다. Transaction commit은, 변경사항이 즉시 데이터 파일까지 flush 되었다는 의미가 아니다. Durability Durability = Commit된 트랜잭션은 장애가 발생해도 반드시 살아남아야 한다는 것이다. ...
MySQL InnoDB의 동작 - 실제 쿼리 상황에서 InnoDB는 어떻게 동작할까? Lock과 Index
RainMind 프로젝트를 수행하면서, 데이터 일관성을 맞추기 위해 이런 쿼리를 사용했었다: @Query(value = """ INSERT INTO schedules (user_id, title, location_id, start_at, end_at) SELECT :use...
Project : RainMind 개발일지 - 14 [2번째 최적화 수행 기록(수치화)]
이번 최적화는 redis 알람 큐의 설계가 적절한지, dequeue 시간 및 메모리 테스트에 관한 것이다. 초반에, redis를 알람 큐로 쓸때 모든 유저의 날씨 알람을 하나의 key에 전부 저장할지, 아니면 유저별로 key를 할당하는 아키텍처가 적절한지 고민했었다. Redis...
Project : RainMind 개발일지 - 13 [schedule 생성 시 lock 확인 at MySQL 콘솔]
성능 최적화를 하며 이런 쿼리를 쓴 적이 있다. @Modifying @Transactional @Query(value = """INSERT INTO schedules (user_id, title, location_id, start_at, end_at) SELECT :user...
Project : RainMind 개발일지 - 12 [1번째 최적화 수행 기록(수치화) - 1st : 회원가입 & 로그인 기능]
회원가입과 로그인 기능 테스트시 사용한 스크립트와 PromQL 쿼리, 데이터 수치화를 기록한다. 회원가입 기능 문제 제시: 수백명의 유저가 지속적으로 회원가입을 수행할 때 처리 속도가 낮아지는 병목 현상 발생. 시나리오: 문제 파악을 위해 100명...
Project : RainMind 개발일지 - 12 [1번째 최적화 수행 기록(수치화) - 2nd : 스케줄 생성]
스케줄 생성 API 테스트시 사용한 스크립트와 PromQL 쿼리, 데이터 수치화를 기록한다. 스케줄 생성 기능 문제 제시: ScheduleService.kt의 scheduleRepository.findAllByUserId(user.id!!).size 부분은, JVM...