| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 31 |
- LV01
- CoffiesVol.02
- Kafka
- docker
- 이것이 자바다
- LV03
- Lv.0
- LV0
- JPA
- Redis
- LV02
- 코테
- AWS
- JMeter
- mysql
- LV.02
- CI/CD
- 데이터 베이스
- 프로그래머스
- 디자인 패턴
- 일정관리프로젝트
- SQL
- 알고리즘
- Join
- spring boot
- nginx
- 연습문제
- Java
- 일정관리 프로젝트
- 포트폴리오
- Today
- Total
목록전체 글 (224)
코드 저장소.
목차1.작성 계기2.테스트 시나리오 및 셋팅3.테스트4.결론 1.작성 계기 지난 부하 테스트까지는 진행했던 것처럼 한 가지 생성 요청을 미친 듯이 반복하는 단순 스트레스 테스트였습니다.그리고 "최대 몇 TPS까지 견디는가?"를 확인하며 시스템 한계점을 찾는 데 집중했습니다. 하지만 실제 유저는 특정 API만 주구장창 연타하지 않으며, 단 하나의 계정으로 동시에 초당 수백 번씩 요청을 보내지도 않습니다. 지금까지의 테스트는 한계점 측정일 뿐, 실제 유저 트래픽 모사와는 거리가 멀었다고 느꼈습니다. 그래서 진짜 부하테스트를 위해 Mixed-Flow, Think-time, 계정별 로그인 세션, 가정 기반 목표 TPS라는 4가지 요소를 도입해 부하 테스트 판을 새로 짜기로 했습니다.2.테스트 시나리오 및 셋팅..
목차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.문제 풀이 과정 우선 이 문제의 요점은 코니가 각 의상의 종류별로 선택할 수 있는 경우의 수를 구하고 그 수를 전부 곱하는 수학적 조합을 구하는 것입니다. 우선은 생각을 해볼 것은 "어떻게 하면 종류별로 옷의 개수를 빠르고 효율적으로 셀 수 있을까?" 하는 점입니다. 이것을 토대로 문제 풀이 과정은 아..