#성능
-
대량 데이터 처리에서 Cursor·Batch·Bulk Insert 비교
수십만~수백만 건을 읽고 쓰는 야간 배치나 데이터 이관은 SQL보다 "몇 번 왕복하고 몇 번 커밋하느냐"가 시간을 정한다. 이 글은 읽는 쪽의 OFFSET 페이징·키셋 페이징·서버 커서와, 쓰는 쪽의 한 건씩 INSERT·JDBC 배치·벌크 로드를 같은 기준왕복, 메모리, 커밋 단위,
-
HikariCP Connection Pool 고갈 원인과 용량 산정
HikariCP 커넥션 풀이 고갈되면 DB는 한가한데 애플리케이션 요청이 30초씩 멈췄다가 한꺼번에 실패한다. 풀 크기를 늘리는 것이 첫 반응이지만, 원인이 커넥션을 오래 잡는 코드라면 늘린 만큼 DB 부하만 커진다. 이 글은 고갈이 어떻게 보이는지, 무엇이 고갈을 만드는지, 지표로 원
-
Rust와 Java의 메모리 관리 및 실행 성능 비교
Rust와 Java는 둘 다 "메모리 안전"을 말하지만 방법이 정반대다. Java는 실행 중에 가비지 컬렉터가 안 쓰는 객체를 찾아 치우고, Rust는 컴파일할 때 소유권 규칙으로 언제 메모리를 해제할지 정해 둔다. 이 차이가 메모리 사용량, 지연의 예측 가능성, 시작 시간, 개발 속도
-
JVM G1 GC와 ZGC의 동작 원리 및 선택 기준
Java 서비스의 P99 지연을 따라가다 보면 결국 GC 멈춤StopTheWorld을 만난다. G1은 JDK 9부터 기본 GC로 대부분의 서비스에 맞게 처리량과 멈춤 시간의 균형을 잡고, ZGC는 힙 크기와 상관없이 멈춤을 1ms 안팎으로 묶는 대신 CPU와 메모리 여유를 더 쓴다. 이
-
P95와 P99가 평균 응답 시간보다 중요한 이유
"평균 응답 시간 0.3초"라는 보고서는 사용자 100명 중 5명이 4초를 기다렸다는 사실을 숨길 수 있다. 응답 시간 분포는 오른쪽으로 긴 꼬리를 갖고, 장애와 민원은 그 꼬리에서 나온다. 이 글은 평균이 왜 사용자 경험을 대변하지 못하는지, P95·P99를 어떻게 재고 합치고 목표로
-
Redis Look-aside Cache 설계와 Cache Stampede 대응
LookasideCacheaside 캐시는 구현이 쉬워서 가장 많이 쓰이지만, 인기 있는 키 하나가 만료되는 순간 수백 개의 요청이 동시에 DB로 몰리는 Cache Stampede를 만든다. 평소에는 DB 부하를 크게 덜어 주던 캐시가 만료 한 번에 DB를 쓰러뜨리는 것이다. 이 글은
-
MyBatis와 JPA 성능 및 유지보수 관점 비교
국내 SI에서 MyBatis와 JPA는 "어느 쪽이 더 빠른가"로 자주 논쟁이 되지만, 실제 성능 차이는 도구보다 쓰는 방법에서 나온다. JPA는 잘못 쓰면 쿼리가 폭증하고, MyBatis는 잘 쓰면 빠르지만 스키마가 바뀔 때마다 고칠 곳이 늘어난다. 이 글은 두 기술을 성능과 유지보수
-
Spring Boot에서 트랜잭션 경계를 잘못 설계하면 발생하는 문제
@Transactional은 붙이기는 쉽지만 경계를 잘못 잡으면 운영에서 가장 찾기 어려운 장애를 만든다. 경계가 너무 넓으면 커넥션 풀이 마르고 락이 길어지고, 너무 좁거나 아예 없으면 절반만 저장된 데이터가 남는다. 이 글은 Spring Boot에서 트랜잭션 경계를 잘못 설계했을 때