범범의 기술블로그

  • 홈
  • 태그
  • 방명록

queue 1

[대기열] Redis만 빠르면 해결될까? - 부하 테스트가 알려준 진짜 병목

k6로 1,000명을 줄 세워봤다 대기열의 진짜 병목은 대기열이 아니었다175 TPS를 설계했는데 10.7이 나왔습니다. 그런데 대기열은 잘 하고 있었습니다. TL;DR이론 175 TPS vs 실측 10.7 TPS, 16배 괴리의 원인은 대기열(Redis)이 아니라 주문 처리(DB)였다.주문 병목(1,298ms)이 Tomcat 스레드를 잡아먹으면서 대기열 API까지 느려지는 캐스케이드가 발생했다.가정을 세우고, 실측으로 깨뜨리고, 괴리를 분석하는 사이클이 성능 설계의 본질이다.175 TPS — 이 숫자는 어디서 나왔나대기열 시스템을 설계할 때 가장 먼저 한 건, “서버가 초당 몇 명을 처리할 수 있는가?”를 산출하는 것이었습니다.DB 커넥션 풀: 50 (HikariCP 설정)주문 1건 처리 시간: 200..

Skill 2026.04.03
이전
1
다음
더보기
프로필사진

범범(백앤드 개발자) BackEndDeveloper

  • 분류 전체보기 (30)
    • Home (1)
    • Skill (7)
    • Spring (8)
    • JPA (1)
    • Querydsl (2)
    • Project (2)
    • Algorithm (6)

Tag

Python, TDD, automicupdate, 부하테스트, K6, 컨트롤러 자동 로깅하기, Spring, 분산형이벤트스트리밍플랫폼, java, 객체형필드, 분산락, Claude, PG결제연동, like문, jpa update 요류, redis, 백준, 낙관적락, NumberFormatExeption, 비관적락,

최근글과 인기글

  • 최근글
  • 인기글

최근댓글

공지사항

페이스북 트위터 플러그인

  • Facebook
  • Twitter

Archives

Calendar

«   2026/05   »
일 월 화 수 목 금 토
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

방문자수Total

  • Today :
  • Yesterday :

Copyright © AXZ Corp. All rights reserved.

티스토리툴바