Performance 40
- TLS 핸드셰이크의 비용 - 세션 재개와 0-RTT의 대가
- 커넥션과 세션 - 커넥션 풀이 실제로 아끼는 것
- 큐잉 이론 한 조각 - 도착률과 서비스율로 파라미터를 정하기
- 직접 만든 마이크로벤치마크는 얼마나 틀리는가 - 결함 넷을 하나씩 재봤다
- JIT 컴파일 - 계층 컴파일, 인라이닝, 역최적화
- CPU 프로파일러가 1순위로 지목한 코드를 고쳤더니 아무 일도 없었다
- 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
- 가상 스레드를 켜서 37배 느려진 엔드포인트 - 핀닝과 상한 없는 admission을 재다
- TCP 연결 수립과 큐 - SYN 백로그, accept 큐, TIME_WAIT
- G1과 ZGC가 p99에 남기는 차이 - 300배 짧은 pause가 꼬리의 11%를 가져갔다
- GC 알고리즘 비교 - G1, ZGC, Shenandoah가 각자 무엇을 포기하는가
- RED와 USE - 어디에 무엇을 붙이는가
- epoll - select, poll과의 차이와 edge, level 트리거
- Spring Batch의 구조 - 청크, 파티셔닝, 재시작과 메타데이터
- 가상 스레드의 내부 - 스케줄러와 캐리어, 핀닝, 그리고 쓰지 않아야 할 때
- Redis 단일 스레드가 멈추는 순간 - SCAN이 3.7배 오래 걸리면서 아무도 막지 않고, 120ms 멈춤이 p99에 안 잡히는 이유
- 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
- 캐시 스탬피드와 single flight - 200명 중 125명이 원본까지 갔고, 예외를 삼키자 실패가 가장 빠른 요청이 됐다
- 백분위 통계 - 평균이 거짓말하는 이유와 히스토그램의 집계 오류
- 키 생성 병목을 추적해 구조를 바꾼 기록: Part 2 - SELECT 안에서 UPDATE가 일어나고 있었다
- 페이지 캐시와 파일 IO - buffered와 direct, fsync가 실제로 하는 일
- 동시성 도구의 비용 - synchronized, ReentrantLock, CAS가 경쟁에서 갈리는 지점
- Postgres 커넥션 하나의 비용 - 풀을 키우면 대기가 사라지는 게 아니라 볼 수 없는 곳으로 옮겨간다
- ParityPay로 검증하는 결제 정합성 2 - 잠금을 필요 이상으로 오래 쥐고 있었다: 추론을 측정으로 바꾼 기록
- 컨텍스트 스위칭과 스케줄링 - CFS, cgroup CPU 제한, 그리고 스로틀링
- 키 생성 병목을 추적해 구조를 바꾼 기록: Part 3 - 채번을 INSERT 시점으로 옮기고 범위 단위로 받기
- Kafka의 저장 구조 - 세그먼트와 오프셋, 페이지 캐시와 zero-copy
- 키 생성 병목을 추적해 구조를 바꾼 기록: Part 1 - INSERT가 느린 줄 알았다
- 대량 배치 안정성을 높이기 위한 구조 개선: Part 3 - 청크 분할과 병렬 처리로 재설계하기
- 대량 배치 안정성을 높이기 위한 구조 개선: Part 1 - 시스템을 압박하기 시작한 배치
- Heap Dump가 가리킨 곳은 데이터가 아니라 영속성 컨텍스트였다: Tasklet에서 Chunk로, XSSF에서 SXSSF로
- 대용량 지분율 데이터 처리 성능 개선과 동시성 제어 전략
- 무거운 엑셀 다운로드 요청을 사전에 판별하는 방법
- 대용량 엑셀 다운로드 요청을 안정적으로 처리하는 방법
- 대량 엑셀 다운로드를 메시지 큐와 S3 사전 생성으로 개선한 이야기
- 조건 기반 예측 캐싱: 고속 엑셀 다운로드 처리 구조 설계
- JPA 활용 2편 복습: API 응답과 조회 전략을 분리하기
- 사용자 공간과 커널 공간 - 시스템 콜, 복사, sendfile과 kTLS
- Large List Rendering Issue
- Increasing System Performance in MultiProcessing