✍🏻기록하는 블로그

vuser 200으로 5분간 성능테스트 시 25번의 HikariPool-1 - Connection is not available, request timed out after 30000ms. SQLTransientConnectionException을 마주했습니다. 왜 Exception이 발생하고, 어떻게 해결했는지 알아봅시다. 이 글은 아래 목차로 구성되어 있습니다. Hikari Connection Pool 동작 방식 Hikari CP Connection 획득 과정 Hikari CP Connection 반납 과정 문제 원인 분석 문제 해결 방법 원인 분석 전에 Hikari Connection pool 획득 및 반환 과정에 대해 알아보겠습니다. Hikari Connection Pool 동작 방식 위에서 Hi..

성능 테스트 시 vuser 임계치를 설정하고, Scouter를 통한 병목구간 분석하여 TPS를 개선한 경험을 공유합니다. Scouter의 XLog 분석하기 Scouter의 xLog를 드래그하면 각 응답마다 아래와 같은 항목들을 볼 수 있습니다. Elasped Time CPU SQL Count SQL Time API Count API Time 위의 항목 중 응답속도 기준(Elasped Time)으로 정렬하여 가 제일 오래 걸린 구간을 확인했습니다. 눈에 띄는 구간은 두 구간이 있었습니다. (1) 구간 - Ngrinder의 RampUp 설정으로 인한 초기 응답속도 지연구간으로 추측했습니다. (2) 구간 - API Time이 올라가여 상세 호출 메서드를 확인하였습니다. 해당 메서드는 ngrinder 테스트 A..

성능테스트 준비항목들을 공유합니다. 튜닝 지점과 고정변수를 지정하여 성능 테스트를 진행하였습니다. 성능 테스트 접근 방식 성능 저하가 발생했을 때 전체 응답 시간에서 차지하는 비중을 분석하여 가장 영향도가 높은 부분부터 집중 분석 대상으로 선택했습니다. 시스템 중요 자원의 사용량 확인, 애플리케이션 서버에서의 자원 사용량 및 응답 시간, 유관 서버와의 통신, 애플리케이션 코드의 성능 비중등을 분석석하였습니다. 성능 테스트 단계 아래 5단계로 구성하였으며, 첫 테스트 이후에는 시나리오 구성을 제외한 4단계가 반복적으로 이루어졌습니다. 성능테스트 시나리오 구상 시스템의 어느 부분에 어떻게 부하를 줄것인지 결정 부하 상황에서 시스템의 동작 예측 필요한 데이터 준비 테스트 환경 구축 서버 수, 서버 스펙 결정 ..

문제상황 member 객체 생성 시 편한 방식으로 객체를 생성하기 위해 lombok의 @Builder을 사용하였다. member 클래스에 필요한 필드를 대상으로 생성자 생성 후 @Builder을 붙여 builder 객체를 생성하게 하였다. @Builder public Member(String id, String password, String userName, String email) { this.id = id; this.password = password; this.userName = userName; this.email = email; } 하지만 필드에 null이 들어왔을 경우가 고려되지 않았다. @Builder에 의해 컴파일 시 생성된 어노테이션 프로세싱 결과를 확인해 보자 public static ..

객체 생성 비용이 비싼 객체 EffectiveJava item6 - 불필요한 객체 생성을 피하라 라는 내용을 회사 코드에 적용한 내용을 정리하여 공유합니다. 스터디 정리 내용 https://github.com/WanOnPreStudy/EffectiveJavaStudy/blob/main/Chapter2/item_6_%EA%B9%80%EC%A0%95%ED%9D%AC.md 책에서는 아래와 같이 설명하고 있습니다. 객체 생성 비용이 비싼 객체는 반복해서 생성하기보다, 캐싱하여객체를 재사용하는 것이 좋다. 객체 생성 비용이 비싼 객체 = cpu 리소스 사용 多 정규표현식의 경우 객체 생성 시 생성 비용이 비싸다. 정규 표현식을 통해 문자열을 검사할 때 내부 메서드를 들여다보면 정규표현식을 파라미터로 받아 내부적으..

B-Tree(B(Balanced)-Tree)란? Database에서 데이터가 저장되는 자료구조 구조 및 특성 RDBMS에서 btree의 변형인 B+Tree, B*-Tree 유형도 사용 인덱스는 테이블의 키 칼럼만 가지고 있으므로 키칼럼을 읽어 실제 데이터가 있는 곳에 가서 조회해야 한다. 최상위 Root Node 중간 Branch Node 하단(실제 데이터 컬럼을 찾아가는 주솟값을 가지고 있음) Leaf Node B-Tree 인덱스 키 추가 및 삭제 인덱스 키 추가, 삭제, 변경 등은 MySQL v5.5 이후 (InnoDB엔진) 체인지 버퍼를 통해 지연 처리 가능 인덱스 키 추가 저장될 키 값을 이용해 B-Tree내부의 적절한 위치 검색 저장될 위치가 정해지면 데이터의 위치를 담는 leaf Node에 저..

트랜잭션 Isolation설명에 필요한 여러 용어를 먼저 정리하자. Transaction 데이터의 정합성을 보장하기 위한 기능 db read, write작업을 논리적으로 묶는 방식 트랜잭션으로 묶은 작업이 성공하면 commit, 실패 시 rollback을 하므로 부분성공, 부분 실패(Partial Update)의 위험이 없음 Lock 동시성을 제어하기 위한 기능 여러 커넥션에서 동시에 동일한 자원을 요청할 경우 순서대로 하나의 커넥션만 변경할 수 있게 하는 역할 Isolation level 동시에 하나 또는 여러 트랜잭션이 진행 될때, 다른 트랜잭션에서 변경된 데이터를 조회하는 기준 일반적인 서비스에서는 Read Commited, Repeatable Read를 사용 Transaction Isolation..

1. InnoDB 스토리지 엔진의 잠금 InnoDB 스토리지 엔진은 인덱스로 레코드를 잠근다. 레코드 단위의 잠금이 가능하며, 레코드와 레코드 사이에 갭을 잠그는 락이 존재 레코드락 InnoDB엔진은 인덱스의 레코드를 잠그며, 인덱스가 생성되지 않아도 InnoDB엔진에서 자동으로 생성되는 클러스터링 인덱스를 통해 레코드 락을 수행한다. 갭락 레코드와 다른 인접한 레코드 사이를 잠그므로 사이에서 데이터가 insert 되는 것을 방지한다. 넥스트 키 락 레코드 락 + 갭 락 자동 증가 락(Auto Increment Lock) Auto Increment 컬럼에 동시에 여러 칼럼에 insert 시 테이블 수준으로 lock이 잡힌다. insert시에만 auto increment 작업이 수행되므로 update, d..