| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- Lv.0
- Java
- docker
- LV0
- 이것이 자바다
- 데이터 베이스
- 포트폴리오
- 코테
- CoffiesVol.02
- JPA
- LV03
- 일정관리프로젝트
- LV.02
- Join
- Redis
- mysql
- JMeter
- SQL
- Kafka
- AWS
- LV01
- 연습문제
- 디자인 패턴
- nginx
- 알고리즘
- 프로그래머스
- LV02
- 일정관리 프로젝트
- spring boot
- CI/CD
- Today
- Total
목록전체 글 (223)
코드 저장소.
목차1.지난 글의 문제점2. 개선 방향 검토3.적용4.CAS 회귀 테스트 1.지난 글의 문제점1-1. 재현 테스트에서 드러난 격차 5편에서 리마인더 DELETE 원인 수정과 테스트 데이터 정리를 마친 뒤 재현 테스트를 진행했고 결과는 기대 이상이었습니다.지표4차5차Average1463ms278msMax5153ms1435ms에러율0.00%0.00%Throughput55.83/sec249.2/sec표를 보면 Average는 5배, Throughput은 4배 이상 개선되었습니다. 그런데 이 좋은 결과가 새로운 계산을 하나 요구했습니다.생성 속도: 249.2건/초폴러 이론상 드레인 속도: 33.3건/초 (3초마다 100건)249.2 ÷ 33.3 ≈ 7.5배 생성 속도가 폴러 드레인 속도의 7.5배에 달했습니다...
목차1. 지난 글에서의 재검토와 원인 분석2. 검증3.결론 1. 지난 글에서의 재검토와 원인 분석3차 결과, 다시 들여다보기3차 테스트에서 에러율은 32.30% → 6.13% → 0.0%까지 떨어졌습니다. 트랜잭션 길이를 줄인 조치(인덱스 추가, 카테고리 캐싱, 리마인더 AFTER_COMMIT 분리)가 정확히 목표했던 효과를 냈고, 붕괴 패턴도 더 이상 관측되지 않았습니다.그런데 이 좋은 소식 뒤에 새로운 문제가 숨어 있었습니다. Outbox Pending Backlog가 0 → 약 900건까지 급등한 것입니다. 1, 2차에서는 backlog가 최대 75건 정도까지만 튀었던 걸 감안하면, 확연히 다른 규모였습니다. 같은 시간대 Scheduler Avg Duration도 폴러 1회 실행당 최대 7.5초까..
목차 1.기존의 한계점2.가설3.테스트4.결론 1.기존의 한계점지난 부하 테스트에서 90VU까지 부하를 올렸을 때, 원래는 Outbox 이벤트의 처리 여부를 Kafka 발행 콜백(whenComplete)에서만 판단했다. 별도의 선점 단계 없이, 폴러가 미발행 이벤트를 가져와 바로 Kafka로 보내고, 콜백이 성공하면 그제서야 sent=true가 되는 구조였습니다. 그리고 당시의 성능 수치는 아래의 표와 같습니다. 지표값처리량84.3TPS에러율8.04%평균 응답시간1225ms붕괴 시점테스트 시작 후 약 1분 37초에 붕괴 변경 전 — JPA dirty-check 기반// OutboxEventEntitypublic void markSent() { this.sent = true; this.sen..
목차1.문제2.문제해결과정3.타인의 코드분석 1.문제 2.문제해결과정2-1.문제 요구사항각 작업의 (요청부터 종료까지 걸린 시간)의 평균을 구해, 최소 정수값(소수점 이하 버림)을 반환하는 알고리즘 구현을 하는 것이 목적핵심 스케줄링 규칙하드디스크는 한 번에 하나의 작업만 수행 가능현재 시점에 요청이 들어와 있는 작업들 중 소요 시간이 가장 짧은 작업을 우선 처리실행 가능한 작업이 없다면, 다음 작업이 요청될 때까지 대기요청 시점이나 소요 시간이 같은 작업이 여러 개일 경우 처리 순서는 임의 지정 가능입력: jobs 배열 (각 요소는 [요청시점(s), 소요시간(l)] 형태)작업 개수: 1 \le jobs의 길이 \le 500요청 시점 s: $0 \le s \le 1,000소요 시간 l: 1 \le..
목차1.문제2.문제해결과정3.타인의 코드 분석 1.문제 2.문제해결과정 2-1. 문제 요구사항입력은 각 행은 (의상의 이름, 의상의 종류)로 이루어진 2차원 문자열 배열하루에 최소 한 개의 의상을 입는다.같은 종류의 의상은 최대 1개만 적용을 할 수 있다. 코트에 적힌 의상과 조합 중 모두 안 입는 경우를 제외하고 서로 다른 옷의 조합의 수를 구해야 한다.출력은 서로 다른 옷의 조합의 수(정수) 2-2.문제 풀이 과정 우선 이 문제의 요점은 코니가 각 의상의 종류별로 선택할 수 있는 경우의 수를 구하고 그 수를 전부 곱하는 수학적 조합을 구하는 것입니다. 우선은 생각을 해볼 것은 "어떻게 하면 종류별로 옷의 개수를 빠르고 효율적으로 셀 수 있을까?" 하는 점입니다. 이것을 토대로 문제 풀이 과정은 아..
목차1.문제2.문제해결과정3.타인의 코드 분석 1.문제 2.문제해결과정2-1. 문제 요구 사항 목표캐릭터가 맵의 좌측 상단 (1, 1)에서 출발하여 상대방 진영인 우측 하단 (n, m) 위치까지 이동할 때, 지나야 하는 칸의 개수의 최솟값을 구해서 return 하고 도착할 수 없을 때는 -1을 return제한사항맵의 크기 n과 m은 각각 1 이상 100 이하의 자연수이다. (n과 m이 모두 1인 경우는 입력으로 주어지지 않음)maps는 0과 1로만 이루어져 있으며, 0은 벽이 있는 자리, 1은 벽이 없는 자리를 나타낸다.처음 캐릭터는 게임 맵의 좌측 상단인 (1, 1) 위치에, 상대방 진영은 우측 하단인 (n, m) 위치에 있다.입출력 예시[[1,0,1,1,1],[1,0,1,0,1],[1,0,1,1,..
