톰캣은 어떻게 수만 개의 요청을 동시에 처리할까

1
// BIO Connector의 동작 방식 (의사 코드)
2
class BIOConnector {
3
    ExecutorService threadPool;
4

5
    void acceptConnection() {
6
        while (true) {
7
            Socket socket = serverSocket.accept();  // 연결 수락
8

9
            // 문제: 스레드 하나가 연결 하나를 전담
10
            threadPool.execute(() -> {
11
                try {
12
                    // 1. 요청 대기 (Blocking!)
13
                    InputStream input = socket.getInputStream();
14
                    byte[] data = readAll(input);  // 데이터 올 때까지 대기
15

16
                    // 2. 요청 처리
17
                    processRequest(data);
18

19
                    // 3. 응답 전송
20
                    OutputStream output = socket.getOutputStream();
21
                    output.write(response);
22

23
                    // 4. 연결 유지 (HTTP Keep-Alive)
24
                    // 스레드가 계속 점유됨!
25
                } finally {
26
                    socket.close();
27
                    // 실제 BIO에서는 Keep-Alive를 처리하려면 루프를 돌며 다음 요청을 기다려야 한다 (여기서는 생략)
28
                }
29
            });
30
        }
31
    }
32
}

1
// 최악의 시나리오
2
class BIOProblem {
3
    public static void main(String[] args) {
4
        // 스레드 풀: 200개
5
        // 동시 연결: 1000개
6
        // Keep-Alive Timeout: 20초
7

8
        // 시나리오:
9
        // 1000명의 사용자가 접속
10
        // 각자 요청 1개만 보내고 Keep-Alive로 20초 대기
11

12
        // 결과:
13
        // - 200개 스레드 모두 점유됨
14
        // - 나머지 800개 연결은 대기
15
        // - 실제로 CPU는 거의 쉬고 있음!
16
    }
17
}

1
// NIO Connector의 동작 방식 (단순화)
2
class NIOConnector {
3
    Selector selector;  // 핵심!
4

5
    void run() {
6
        while (true) {
7
            // 1. Selector가 여러 연결을 동시에 감시
8
            int readyCount = selector.select();  // Blocking이지만 여러 채널을 감시
9

10
            // 2. 준비된 채널만 처리
11
            Set<SelectionKey> keys = selector.selectedKeys();
12
            for (SelectionKey key : keys) {
13
                if (key.isAcceptable()) {
14
                    // 새 연결 수락
15
                    acceptConnection(key);
16
                } else if (key.isReadable()) {
17
                    // 데이터 읽기 준비됨 → 이때만 워커 스레드 할당!
18
                    handleRead(key);
19
                } else if (key.isWritable()) {
20
                    // 데이터 쓰기 준비됨
21
                    handleWrite(key);
22
                }
23
            }
24
        }
25
    }
26
}

1
# 테스트 환경
2
spring:
3
  application:
4
    name: benchmark-test
5
server:
6
  tomcat:
7
    threads:
8
      max: 200

1
// 느린 API (의도적으로 3초 대기)
2
@RestController
3
class SlowController {
4

5
    @GetMapping("/slow")
6
    public String slowApi() throws InterruptedException {
7
        Thread.sleep(3000);  // DB 조회나 외부 API 호출 시뮬레이션
8
        return "Done";
9
    }
10
}

1
동시 사용자: 1000명
2
요청: GET /slow
3

4
결과:
5
- 처음 200개: 3초 후 응답
6
- 201~400번: 6초 후 응답
7
- 401~600번: 9초 후 응답
8
- 601~800번: 12초 후 응답
9
- 801~1000번: 15초 후 응답
10

11
평균 응답 시간: 9초

1
동시 사용자: 1000명
2
요청: GET /slow
3

4
결과:
5
- 1000개 모두 약 3~4초 후 응답
6
- Poller가 1000개 연결을 모두 관리
7
- 워커 스레드는 실제 처리 시에만 할당
8

9
평균 응답 시간: 3.2초

1
BIO:
2
연결 수 > 스레드 수 → 큐에서 대기 → 순차 처리
3

4
NIO:
5
연결 수와 무관 → Poller가 모두 감시 → 준비된 것만 워커 스레드 할당

1
// Acceptor의 역할 (의사 코드)
2
class Acceptor implements Runnable {
3
    ServerSocketChannel serverSocket;
4

5
    @Override
6
    public void run() {
7
        while (running) {
8
            // 1. 3-way handshake 완료된 연결 수락
9
            SocketChannel socket = serverSocket.accept();  // Blocking
10

11
            // 2. Non-blocking 모드로 설정
12
            socket.configureBlocking(false);
13

14
            // 3. Poller에게 넘김
15
            PollerEvent event = new PollerEvent(socket, OP_READ);
16
            poller.register(event);
17
        }
18
    }
19
}

1
// accept()는 빠르다
2
class AcceptorPerformance {
3
    void benchmark() {
4
        long start = System.nanoTime();
5
        SocketChannel socket = serverSocket.accept();
6
        long end = System.nanoTime();
7

8
        System.out.println("Accept time: " + (end - start) / 1000 + "μs");
9
        // 출력: Accept time: 50μs (0.05ms)
10

11
        // 초당 처리 가능: 1,000,000 / 50 = 20,000 connections/sec
12
        // 실제로는 TCP 백로그 큐에서 꺼내기만 하므로 매우 빠름
13
    }
14
}

1
// Poller의 역할 (의사 코드)
2
class Poller implements Runnable {
3
    Selector selector;
4
    Queue<PollerEvent> events;
5

6
    @Override
7
    public void run() {
8
        while (running) {
9
            // 1. 새로 등록된 소켓을 Selector에 등록
10
            processEvents();
11

12
            // 2. Selector로 준비된 채널 감지
13
            int count = selector.select(1000);  // 최대 1초 대기
14

15
            if (count > 0) {
16
                // 3. 준비된 채널 처리
17
                Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
18
                while (iterator.hasNext()) {
19
                    SelectionKey key = iterator.next();
20
                    iterator.remove();
21

22
                    if (key.isReadable()) {
23
                        // 데이터 읽기 준비됨!
24
                        // Executor에게 넘김
25
                        executor.execute(new SocketProcessor(key));
26
                    }
27
                }
28
            }
29
        }
30
    }
31

32
    void processEvents() {
33
        PollerEvent event;
34
        while ((event = events.poll()) != null) {
35
            // Acceptor가 넘긴 소켓을 Selector에 등록
36
            event.socket.register(selector, SelectionKey.OP_READ);
37
        }
38
    }
39
}

1
// Before (BIO): 1000개 연결 = 1000개 스레드 필요
2
// 메모리: 1000 × 1MB = 1GB
3

4
// After (NIO): 1000개 연결 = Poller 1개(8.5+ 고정) + 필요할 때만 워커 스레드
5
// 메모리: 2MB (Poller) + 동적 할당

1
// Executor의 역할
2
class SocketProcessor implements Runnable {
3
    SelectionKey key;
4

5
    @Override
6
    public void run() {
7
        try {
8
            // 1. 소켓에서 데이터 읽기
9
            SocketChannel channel = (SocketChannel) key.channel();
10
            ByteBuffer buffer = ByteBuffer.allocate(8192);
11
            int read = channel.read(buffer);
12

13
            // 2. HTTP 요청 파싱
14
            HttpRequest request = parseHttpRequest(buffer);
15

16
            // 3. 서블릿 컨테이너에 전달
17
            servlet.service(request, response);
18

19
            // 4. 응답 전송
20
            channel.write(responseBuffer);
21

22
        } finally {
23
            // 5. 워커 스레드 즉시 반환!
24
            // Keep-Alive 연결은 다시 Poller로
25
            key.interestOps(SelectionKey.OP_READ);
26
        }
27
    }
28
}

1
BIO:
2
스레드 할당 → 데이터 대기 (2초) → 처리 (0.1초) → 대기 (Keep-Alive 20초)
3
스레드 점유 시간: 22.1초
4

5
NIO:
6
Poller 감시 (2초) → 스레드 할당 → 처리 (0.1초) → 스레드 반환 → Poller 감시 (20초)
7
스레드 점유 시간: 0.1초

1
// Java Selector의 내부 동작 (Linux)
2
class EPollSelectorImpl extends SelectorImpl {
3

4
    int poll(long timeout) {
5
        // JNI를 통해 리눅스 epoll_wait 시스템 콜 호출
6
        return EPoll.wait(pollArrayAddress, NUM_EPOLLEVENTS, timeout, epfd);
7
    }
8
}

1
// 리눅스 커널 수준
2
// 1. epoll 인스턴스 생성
3
int epfd = epoll_create1(0);
4

5
// 2. 감시할 소켓 등록
6
struct epoll_event ev;
7
ev.events = EPOLLIN;  // 읽기 이벤트
8
ev.data.fd = socket_fd;
9
epoll_ctl(epfd, EPOLL_CTL_ADD, socket_fd, &ev);
10

11
// 3. 이벤트 대기 (Blocking이지만 여러 소켓 동시 감시!)
12
struct epoll_event events[1000];
13
int nfds = epoll_wait(epfd, events, 1000, timeout);
14

15
// 4. 준비된 소켓만 순회
16
for (int i = 0; i < nfds; i++) {
17
    if (events[i].events & EPOLLIN) {
18
        // 이 소켓은 읽을 데이터가 있음!
19
        handle_read(events[i].data.fd);
20
    }
21
}

1
// select (옛날 방식)
2
fd_set readfds;
3
FD_ZERO(&readfds);
4
FD_SET(socket1, &readfds);
5
FD_SET(socket2, &readfds);
6
// ... 1000개 등록 ...
7

8
select(max_fd, &readfds, NULL, NULL, &timeout);
9

10
// 문제: 1000개를 매번 순회하며 확인
11
for (int i = 0; i < 1000; i++) {
12
    if (FD_ISSET(sockets[i], &readfds)) {
13
        // 준비됨
14
    }
15
}
16
// 시간 복잡도: O(N)
17

18
// epoll (새로운 방식)
19
int nfds = epoll_wait(epfd, events, 1000, timeout);
20
// 커널이 준비된 것만 events 배열에 채워줌!
21

22
for (int i = 0; i < nfds; i++) {
23
    // 이미 준비된 것만 순회
24
}
25
// 시간 복잡도: O(준비된 개수)

1
연결 1000개 중 10개만 준비된 경우:
2

3
select: 1000개 FD 순회 → 수십~수백μs
4
epoll:  ready FD만 반환 → 수μs
5

6
연결 수가 많아질수록 차이가 벌어진다 (수만 연결 이상에서 수십배 이상)

1
server:
2
  tomcat:
3
    threads:
4
      max: 200              # maxThreads
5
    max-connections: 8192   # maxConnections
6
    accept-count: 100       # acceptCount

1
// maxThreads = 200이면?
2
class WorkerThreadPool {
3
    ExecutorService executor = Executors.newFixedThreadPool(200);
4

5
    void handleRequest(HttpRequest request) {
6
        if (executor.getActiveCount() < 200) {
7
            // 처리 가능
8
            executor.submit(() -> processRequest(request));
9
        } else {
10
            // 대기 (연결은 유지됨!)
11
            // Poller가 계속 감시
12
        }
13
    }
14
}

1
# 시나리오 1: CPU 바운드 작업 (계산 위주)
2
# 평균 처리 시간: 100ms
3
# CPU 코어: 8개
4
# 권장: threads.max = 8~16
5

6
# 시나리오 2: I/O 바운드 작업 (DB, 외부 API 호출 위주)
7
# 평균 처리 시간: 500ms (그 중 450ms는 I/O 대기)
8
# CPU 코어: 8개
9
# 권장: threads.max = 100~200
10

11
# 시나리오 3: 혼합
12
# 평균 처리 시간: 200ms (그 중 150ms는 I/O 대기)
13
# CPU 코어: 8개
14
# 권장: threads.max = 50~100

1
// NIO에서 maxConnections의 의미
2
class NIOEndpoint {
3
    Semaphore connectionLimitLatch;  // 연결 수 제한
4

5
    void setMaxConnections(int max) {
6
        this.connectionLimitLatch = new Semaphore(max);
7
    }
8

9
    void acceptConnection(SocketChannel socket) {
10
        if (connectionLimitLatch.tryAcquire()) {
11
            // 연결 수락
12
            poller.register(socket);
13
        } else {
14
            // 더 이상 연결 받을 수 없음
15
            // OS accept queue로 이동 (acceptCount)
16
        }
17
    }
18

19
    void closeConnection(SocketChannel socket) {
20
        socket.close();
21
        connectionLimitLatch.release();  // 슬롯 반환
22
    }
23
}

1
메모리 계산:
2
- 연결 하나당 메모리: 약 50~100KB (TCP 버퍼, 소켓 메타데이터)
3
- 8192개 연결: 400MB~800MB
4

5
CPU 계산:
6
- Poller의 epoll_wait: O(준비된 개수)
7
- 8192개 중 100개 준비: 1ms 미만
8

9
대부분의 경우 충분!

1
# 잘못된 상황
2
server:
3
  tomcat:
4
    max-connections: 10000
5
    threads:
6
      max: 200
7

8
# 문제: 10000개 연결이 들어오면?
9
# - 200개만 처리 중
10
# - 9800개는 대기
11
# - 메모리만 낭비!
12

13
# 올바른 설정
14
# NIO 환경에서는 유휴 연결을 Poller가 효율적으로 관리하므로
15
# 기본값 8192가 대부분의 경우 적합하다.
16
# 메모리가 제한적인 환경에서만 낮추는 것을 고려한다.
17
server:
18
  tomcat:
19
    max-connections: 8192
20
    threads:
21
      max: 200

1
// ServerSocket 생성 시
2
ServerSocket serverSocket = new ServerSocket(port, acceptCount);
3

4
// 리눅스에서 실제 동작
5
// listen(sockfd, backlog)
6
listen(server_fd, 100);  // acceptCount = 100

1
시나리오:
2
maxConnections = 10
3
acceptCount = 5
4
현재 연결: 10개 (가득 참)
5

6
새 연결 요청:
7
1. Tomcat: "maxConnections 가득 참, accept 안 함"
8
2. OS: "그럼 내가 받아서 큐에 넣어둘게" (최대 5개)
9
3. 클라이언트: "연결 성공!" (사실은 대기 중)
10

11
만약 acceptCount도 가득 차면:
12
4. OS: "더 이상 못 받음"
13
5. 클라이언트: "Connection refused" 에러

1
# Netflix의 설정 (추정)
2
server:
3
  tomcat:
4
    threads:
5
      max: 300
6
    max-connections: 400
7
    accept-count: 10    # 매우 작게!

1
큰 acceptCount (예: 1000):
2
- 연결은 성공하지만 30초 동안 대기
3
- 사용자: "왜 이렇게 느려?" (나쁜 UX)
4

5
작은 acceptCount (예: 10):
6
- 빠르게 "Connection refused" 반환
7
- 클라이언트: 재시도 또는 다른 서버로 라우팅 (빠른 실패)

1
# 내가 현재 작업하고 있는 사이드 스트리밍 서비스 (I/O 위주)
2
server:
3
  tomcat:
4
    threads:
5
      max: 200
6
      min-spare: 50
7
    max-connections: 500
8
    accept-count: 20
9
    connection-timeout: 20000
10

11
# API 서버 (빠른 응답)
12
server:
13
  tomcat:
14
    threads:
15
      max: 100
16
      min-spare: 20
17
    max-connections: 200
18
    accept-count: 10
19
    connection-timeout: 5000
20

21
# 내부 관리 도구 (트래픽 적음)
22
server:
23
  tomcat:
24
    threads:
25
      max: 50
26
      min-spare: 10
27
    max-connections: 100
28
    accept-count: 10

1
// DispatcherServlet의 핵심 메서드 (단순화)
2
public class DispatcherServlet extends HttpServlet {
3

4
    private List<HandlerMapping> handlerMappings;
5
    private List<HandlerAdapter> handlerAdapters;
6
    private List<ViewResolver> viewResolvers;
7

8
    protected void doDispatch(HttpServletRequest request,
9
                             HttpServletResponse response) {
10

11
        // 1. HandlerMapping으로 컨트롤러 찾기
12
        HandlerExecutionChain handler = getHandler(request);
13
        if (handler == null) {
14
            response.sendError(404);
15
            return;
16
        }
17

18
        // 2. HandlerAdapter 찾기
19
        HandlerAdapter adapter = getHandlerAdapter(handler.getHandler());
20

21
        // 3. Interceptor - preHandle
22
        if (!handler.applyPreHandle(request, response)) {
23
            return;
24
        }
25

26
        // 4. 실제 컨트롤러 실행
27
        ModelAndView mv = adapter.handle(request, response, handler.getHandler());
28

29
        // 5. Interceptor - postHandle
30
        handler.applyPostHandle(request, response, mv);
31

32
        // 6. View 렌더링 (REST API는 생략)
33
        if (mv != null) {
34
            render(mv, request, response);
35
        }
36

37
        // 7. Interceptor - afterCompletion
38
        handler.triggerAfterCompletion(request, response, null);
39
    }
40
}

1
// HandlerMapping의 역할
2
@RestController
3
@RequestMapping("/api/streams")
4
class StreamController {
5

6
    @GetMapping("/{id}")  // 이 매핑 정보를 HandlerMapping이 관리
7
    public StreamDto getStream(@PathVariable Long id) {
8
        return streamService.findById(id);
9
    }
10
}
11

12
// HandlerMapping이 관리하는 맵 (단순화)
13
class RequestMappingHandlerMapping {
14

15
    Map<RequestMappingInfo, HandlerMethod> mappings = new HashMap<>();
16

17
    void registerMapping() {
18
        // 애플리케이션 시작 시 등록
19
        RequestMappingInfo info = new RequestMappingInfo(
20
            "/api/streams/{id}",
21
            RequestMethod.GET
22
        );
23

24
        HandlerMethod method = new HandlerMethod(
25
            streamController,          // 빈
26
            "getStream",               // 메서드 이름
27
            Long.class                 // 파라미터 타입
28
        );
29

30
        mappings.put(info, method);
31
    }
32

33
    HandlerMethod getHandler(HttpServletRequest request) {
34
        String uri = request.getRequestURI();      // "/api/streams/123"
35
        String method = request.getMethod();        // "GET"
36

37
        // 매핑 찾기
38
        for (Entry<RequestMappingInfo, HandlerMethod> entry : mappings.entrySet()) {
39
            if (entry.getKey().matches(uri, method)) {
40
                return entry.getValue();  // StreamController.getStream
41
            }
42
        }
43

44
        return null;  // 404
45
    }
46
}

1
// Spring은 여러 HandlerMapping을 순서대로 시도
2
List<HandlerMapping> handlerMappings = Arrays.asList(
3
    new RequestMappingHandlerMapping(),  // @RequestMapping
4
    new BeanNameUrlHandlerMapping(),      // 빈 이름으로 매핑
5
    new SimpleUrlHandlerMapping()         // 직접 URL 매핑
6
);
7

8
HandlerExecutionChain getHandler(HttpServletRequest request) {
9
    for (HandlerMapping mapping : handlerMappings) {
10
        HandlerExecutionChain handler = mapping.getHandler(request);
11
        if (handler != null) {
12
            return handler;
13
        }
14
    }
15
    return null;
16
}

1
// 형태 1: @Controller 애너테이션
2
@RestController
3
class ModernController {
4
    @GetMapping("/api/users")
5
    public List<User> getUsers() {
6
        return userService.findAll();
7
    }
8
}
9

10
// 형태 2: Controller 인터페이스 구현 (옛날 방식)
11
class OldSchoolController implements Controller {
12
    @Override
13
    public ModelAndView handleRequest(HttpServletRequest req,
14
                                     HttpServletResponse res) {
15
        // ...
16
    }
17
}
18

19
// 형태 3: HttpRequestHandler
20
class SimpleController implements HttpRequestHandler {
21
    @Override
22
    public void handleRequest(HttpServletRequest req,
23
                             HttpServletResponse res) {
24
        // ...
25
    }
26
}

1
// HandlerAdapter 인터페이스
2
interface HandlerAdapter {
3
    boolean supports(Object handler);  // 이 핸들러 처리 가능?
4
    ModelAndView handle(HttpServletRequest req,
5
                       HttpServletResponse res,
6
                       Object handler);
7
}
8

9
// 예시: RequestMappingHandlerAdapter
10
class RequestMappingHandlerAdapter implements HandlerAdapter {
11

12
    @Override
13
    public boolean supports(Object handler) {
14
        return handler instanceof HandlerMethod;  // @RequestMapping 메서드
15
    }
16

17
    @Override
18
    public ModelAndView handle(HttpServletRequest req,
19
                              HttpServletResponse res,
20
                              Object handler) {
21
        HandlerMethod method = (HandlerMethod) handler;
22

23
        // 1. 파라미터 리졸빙
24
        Object[] args = resolveArguments(method, req);
25
        // @PathVariable, @RequestBody 등 처리
26

27
        // 2. 메서드 실행
28
        Object result = method.invoke(args);
29

30
        // 3. 반환값 처리
31
        if (method.isAnnotatedWith(ResponseBody.class)) {
32
            // MessageConverter로 JSON 변환
33
            writeJson(res, result);
34
            return null;
35
        }
36

37
        return new ModelAndView("viewName", result);
38
    }
39
}

1
@RestController
2
class PerformanceController {
3

4
    @GetMapping("/api/benchmark")
5
    public String benchmark() {
6
        // 각 단계별 시간 측정
7
        return "OK";
8
    }
9
}

1
// 느린 Controller
2
@GetMapping("/api/slow")
3
public List<UserDto> getUsers() {
4
    // 1. DB 조회: 100ms
5
    List<User> users = userRepository.findAll();
6

7
    // 2. N+1 문제: 500ms
8
    for (User user : users) {
9
        user.getOrders().size();  // Lazy Loading
10
    }
11

12
    // 3. DTO 변환: 50ms
13
    return users.stream()
14
        .map(UserDto::from)
15
        .collect(Collectors.toList());
16
}
17

18
// 총 시간: 650ms
19
// Spring MVC 오버헤드: 2.5ms (0.4%)
20
// 실제 로직: 650ms (99.6%)

1
// 문제가 있던 코드 (단순화)
2
@Configuration
3
class UserGradeBatchConfig {
4

5
    @Bean
6
    fun updateUserGradeJob(): Job {
7
        return jobBuilderFactory.get("updateUserGrade")
8
            .start(updateGradeStep())
9
            .build()
10
    }
11

12
    @Bean
13
    fun updateGradeStep(): Step {
14
        return stepBuilderFactory.get("updateGrade")
15
            .<User, User>chunk(1000)
16
            .reader(userReader())
17
            .processor(gradeProcessor())  // 문제!
18
            .writer(userWriter())
19
            .build()
20
    }
21
}
22

23
// Processor: 외부 API 호출
24
class GradeProcessor : ItemProcessor<User, User> {
25
    override fun process(user: User): User {
26
        // 외부 API 호출: 150ms
27
        val point = externalApi.getUserPoint(user.id)  // Blocking!
28
        user.grade = calculateGrade(point)
29
        return user
30
    }
31
}

1
Chunk 크기: 1,000
2
외부 API 응답 시간: 150ms
3
총 레코드: 50,000개
4

5
처리 과정:
6
1. 1,000개 읽기
7
2. 1,000개 처리 (각 150ms) = 150,000ms (2.5분)
8
3. 1,000개 쓰기
9
4. 다음 청크...
10

11
총 시간: 50 chunks × 2.5분 = 125분 (2시간)

1
class ParallelGradeProcessor : ItemProcessor<User, User> {
2

3
    override fun process(user: User): User {
4
        // RxKotlin으로 병렬 처리
5
        return Observable.just(user)
6
            .flatMap { u ->
7
                Observable.fromCallable {
8
                    externalApi.getUserPoint(u.id)
9
                }
10
                .subscribeOn(Schedulers.io())  // 병렬 실행!
11
            }
12
            .map { point ->
13
                user.grade = calculateGrade(point)
14
                user
15
            }
16
            .blockingFirst()
17
    }
18
}

1
// 문제: 단건 업데이트 1,000번
2
UPDATE users SET grade = 'GOLD' WHERE id = 1;
3
UPDATE users SET grade = 'GOLD' WHERE id = 2;
4
// ... 1,000번 반복
5

6
// 해결: 등급별로 그룹화하여 IN UPDATE
7
UPDATE users SET grade = 'GOLD' WHERE id IN (1, 2, 3, ..., 500);
8
UPDATE users SET grade = 'SILVER' WHERE id IN (501, 502, ..., 800);
9
UPDATE users SET grade = 'BRONZE' WHERE id IN (801, 802, ..., 1000);
10

11
// 1,000번 → 3번!

1
# 기존 설정
2
server:
3
  tomcat:
4
    threads:
5
      max: 200

1
2025-01-10 14:23:15 WARN  o.a.tomcat.util.threads.ThreadPoolExecutor
2
- Pool exhausted with 200 threads, queue is full
3

4
2025-01-10 14:23:16 ERROR o.s.web.servlet.DispatcherServlet
5
- Handler dispatch failed: java.util.concurrent.RejectedExecutionException

1
// 문제가 있던 API
2
@GetMapping("/api/streams/live")
3
public List<StreamDto> getLiveStreams() {
4
    // 1. DB 조회 (느린 쿼리): 5초
5
    List<Stream> streams = streamRepository.findAllLive();
6

7
    // 2. N+1 문제: 10초
8
    for (Stream stream : streams) {
9
        stream.getUser().getNickname();  // Lazy Loading
10
        stream.getTags().size();          // Lazy Loading
11
    }
12

13
    return streams.stream()
14
        .map(StreamDto::from)
15
        .collect(Collectors.toList());
16
}
17

18
// 총 처리 시간: 15초
19
// maxThreads = 200
20
// 초당 요청: 20개
21

22
// 15초 × 20 req/s = 300개 스레드 필요!
23
// 하지만 200개만 있음 → 고갈!

1
// Fetch Join으로 N+1 해결
2
@Query("""
3
    SELECT s FROM Stream s
4
    JOIN FETCH s.user
5
    JOIN FETCH s.tags
6
    WHERE s.status = 'LIVE'
7
""")
8
List<Stream> findAllLiveWithFetch();
9

10
// 처리 시간: 15초 → 0.5초
11
// 필요 스레드: 0.5초 × 20 req/s = 10개

1
@Cacheable("liveStreams")
2
@GetMapping("/api/streams/live")
3
public List<StreamDto> getLiveStreams() {
4
    // 캐시 히트: 10ms
5
    // 캐시 미스: 500ms (쿼리 최적화 후)
6
    return streamService.findAllLive();
7
}
8

9
// 필요 스레드: 거의 없음 (대부분 캐시 히트)

1
server:
2
  tomcat:
3
    threads:
4
      max: 200
5
    max-connections: 10000  # 너무 크다!

1
동시 연결: 10,000개
2
워커 스레드: 200개
3

4
상황:
5
- 10,000개 연결 모두 Poller가 관리
6
- 하지만 200개만 동시 처리 가능
7
- 9,800개는 대기만 함
8
- 메모리: 10,000 × 100KB = 1GB 낭비!

1
server:
2
  tomcat:
3
    threads:
4
      max: 200
5
    max-connections: 8192   # NIO에서는 Poller가 유휴 연결을 효율적으로 관리하므로 기본값이 적합
6
    accept-count: 20        # 빠른 실패

1
NIO 환경에서는 유휴 연결을 Poller가 효율적으로 관리하므로
2
기본값 8192가 대부분의 경우 적합하다.
3
메모리가 제한적인 환경에서만 낮추는 것을 고려한다.