http persistence connection 과 thread pool with(SSE)

SSE 로 서버에서 클라이언트로의 단방향 통신을 구현하며 생긴 궁금증

• 기본적으로 http는 비연결성, 무상태 프로토콜로 한번의 요청과 응답으로 역할이 끝나게 된다.
• 하지만 SSE는 구독 요청 → 특정 이벤트 발생 시 요청이 오지 않음에도 서버에서 클라이언트로 데이터를 전송할 수 있다.
• 이러한 기술을 구현할 수 있도록 하는 것 ! → http persistence connection이라는 것 까지는 도달할 수 있었다.
  • 의문점
    • spring에서 사용하는 서블릿 컨테이너에 스레드 풀 기본 값은 200이다.
    • SSE를 구현할 시 동시에 200명이 SSE알림을 받기 위해 구독을 한 상황
      • 이때 서버에서 클라이언트로 데이터를 계속 보내기 위해서는 연결을 지속해야한다. 그 말은 어떠한 서버자원을 계속 점유하고 있어야한다.(I/O발생 끊기지 않은 상황)
      • 그렇다면 그 이후로 다른 request가 왔을 때 큐 에서 계속 대기해야하는 상황이 생기지 않을까..???? 모든 스레드 자원이 연결을 지속하기 위한 목적으로 반납되지 않는 상황이라고 생각되었다.
  • 해소
    • 나와 같은 생각을 가진 질문이 10년전에 올라왔었고 답변들을 보면
    • 서버의 스레딩 모델에 따라 다르고 apache는 기본적으로 연결당 하나의 스레드를 사용하므로 대기 한다고 나와있다.
      • 동접자수가 특정값을 넘어간다면 폴링이 더 적합한 선택일 지도 모른다.
      • 비동기적인 처리를 한다면 이를 해결 할 수 있을지도..?(NIO, webflux등 공부해봐야겠다.)
  • https://stackoverflow.com/questions/14225501/server-sent-events-costs-at-server-side

  2023-06-25

  해당 문제에 대한 테스트를 진행해보았다.

package com.example.ssetest.controller;

import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;

import java.util.Map;
import java.util.UUID;
import java.util.concurrent.ConcurrentHashMap;

@Slf4j
@RestController
public class SseController {
    private static final Map<String, SseEmitter> sseEmitters = new ConcurrentHashMap<>();

    @GetMapping(value = "sub",produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public ResponseEntity<SseEmitter> connect(HttpServletResponse response){
        String userId = UUID.randomUUID().toString();
        log.info("시작 {}",userId);

        SseEmitter sseEmitter = new SseEmitter(100000L * 45L);

        sseEmitters.put(userId, sseEmitter);
        log.info("id 값은 {}",sseEmitters.keySet());

        sseEmitter.onCompletion(()->{
            log.info("onCompletion sseEmitters {}",userId);
            sseEmitters.remove(userId);
        });
        sseEmitter.onTimeout(() -> {
            log.info("onTimeout sseEmitter {}",userId);
            sseEmitters.remove(userId);
        });
        sseEmitter.onError((e) -> {
            log.info("Error seeEmitter {}", userId);
            sseEmitters.remove(userId);
        });

        try {
            sseEmitter.send(SseEmitter.event().name("connect").data("Connection"));
        } catch (Exception e) {
            e.printStackTrace();
        }

        return ResponseEntity.ok(sseEmitter);
    }
    @GetMapping("/sleep")
    public ResponseEntity<String> sleepM() throws Exception{
        Thread.sleep(10000000);
        return ResponseEntity.ok("Sleep");
    }
    @GetMapping("/answer")
    public ResponseEntity<String> answer(){
        return ResponseEntity.ok("answer");
    }
}

테스트 시나리오

server.tomcat.max-connections=5
server.tomcat.threads.max=5

• 톰캣의 쓰레드 수를 5개로, 커넥션을 5개로 제한해보았다.
  1. sleep을 5번 호출 → answer 호출
     • answer에 대한 응답이 오지 않음
  2. sub를 5번 호출 → answer 호출
     • answer에 대한 응답이 오지 않음

쓰레드를 timeout 동안은 점유하고 있다는 생각이 들었다. but 테스트의 전제가 잘못되었다는 것을 깨닫고 다시 테스트를 해보았음

# 톰캣서버의 가용가능한 최대 쓰레드는 5개로 설정
server.tomcat.threads.max=5
# 기동시점부터 최소로 유지되어야 하는 쓰레드는 5개
server.tomcat.threads.min-spare=5

1. sleep을 5번 호출 → answer 호출
   • answer에 대한 응답이 오지 않음
2. sub를 5번 호출 → answer 호출
   • answer에 대한 응답이 왔음

어떻게 된 일일까? 쓰레드를 점유하고 있는 것이 아닌가? max-connection을 기반으로 테스트를 해보았다.

server.tomcat.max-connections=3

1. sleep을 5번 호출 → answer 호출
   • answer에 대한 응답이 오지 않음
2. sub를 5번 호출 → answer 호출
   • answer에 대한 응답이 오지 않음

테스트 결과로 볼 때 기존에 생각했던 것 과는 다른 결론이 나왔다.

• 기존의 내 생각 Thread가 반환되지 못하고 이벤트 발생을 기다릴 것이다.
• 테스트 결과
  • Thread에 제한을 두었지만, 다른 요청을 받을 수 있다.
  • Max-Connection에 제한을 두니, 다른 요청을 받을 수 없었다.

이를 이해하기 위해 tomcat 여러가지 자료들을 찾아보았다.

• 먼저 현재 내가 사용하고 있는 톰캣의 버전은 10버전이다.
• tomcat은 9.0버전 부터 BIO connector를 지원하지 않는다고 한다.

BIO Connector란?

• Socket Connection을 처리할 때 Java의 기본적인 IO 기술을 사용
• Thread Pool에 관리되는 thread는 소켓 연결을 받고 요청을 처리하고 요청에 대해 응답한 후 소켓 연결이 종료되면 pool에 다시 돌아오게 된다.
• 즉, connection이 닫힐 때까지 하나의 thread는 특정 connection에 계속 할당되어 있다.
  • 내가 가진 궁금증은 이러한 배경을 바탕으로 발생하였던 것!
• 이러한 방식으로 Thread를 할당하여 사용할 경우, 동시에 사용되는 thread 수가 동시 접속할 수 있는 사용자의 수가 된다.
• 이러한 방식을 채택하여 사용할 경우 thread들이 충분히 사용되지 않고 idle 상태로 낭비되는 시간이 많이 발생한다.
• 이러한 문제점을 해결하고자 NIO Connector가 등장!
• 간단하게 BIO Connector는 Acceptor가 소켓을 획득하고 worker thread pool에서 socket을 처리하기 위한 idle 상태인 worker thread를 찾는다.
• 만약 Worker thread pool에 idle thread가 없다면, 요청을 처리할 thread가 없기 때문에 Acceptor는 block 된다.
• 중요한 점은 Connector 내부에서 각 요청에 상응하는 Thread를 Workde Thread Pool에서 꺼내서 1:1로 매핑해준다.

그렇다면 NIO Connector란?

• BIO와 달리 새로운 연결이 발생할 때, 바로 새로운 Thread를 할당하지 않고(Connection이 Thread와 1:1 매핑 관계가 아니다.) Poller라는 개념의 Thread에게 Connection(Channel)을 넘겨준다.
• Poller는 Socket들을 캐시로 들고 있다가 해당 Socket에서 data에 대한 처리가 가능한 순간에만 thread를 할당하는 방식을 사용해서 thread가 idle 상태로 낭비되는 시간을 줄여준다.

tomcat이 NIO 방식으로 동작하여 Thread와 1:1 매핑관계가 아니기 때문에 이러한 테스트 결과가 나왔다고 생각한다

• 앞으로 I/O MultiPlexing과 웹플럭스에 대해서도 공부할 생각이다.