クイズ: コネクタとスレッドプール

acceptCount 까지 모두 소진됐을 때 클라이언트가 받게 되는 것은?

• HTTP 503 Service Unavailable
• TCP 연결 거부 (Connection refused)
• HTTP 429 Too Many Requests
• HTTP 504 Gateway Timeout

maxConnections 가 maxThreads 보다 훨씬 커도 되는 이유는?

• NIO 커넥터에서는 요청을 보내지 않는 Keep-Alive 유휴 커넥션이 워커 스레드를 점유하지 않기 때문
• 톰캣이 스레드를 자동으로 늘려 주기 때문
• maxConnections 는 실제로 동작하지 않는 설정이기 때문
• OS 가 커넥션을 자동으로 정리하기 때문

스레드 덤프를 떴더니 http-nio 스레드 대부분이 HikariPool.getConnection 에서 WAITING 상태였습니다. 가장 적절한 조치는?

• maxThreads 를 두 배로 늘린다
• acceptCount 를 늘린다
• DB 커넥션 풀 크기와 느린 쿼리를 먼저 확인한다
• Keep-Alive 를 비활성화한다

목표 처리량 500 TPS, 평균 응답시간 400ms 일 때 리틀의 법칙으로 계산한 최소 동시 처리 수는?

• 50 — 500 을 응답시간 10 으로 나눈 값
• 125 — 500 을 4 로 나눈 값
• 200 — 500 × 0.4초
• 1250 — 500 을 0.4 로 나눈 값

connectionTimeout="20000" 이 제한하는 것은?

• 애플리케이션이 요청을 처리하는 최대 시간
• DB 커넥션을 얻기까지 기다리는 시간
• Keep-Alive 커넥션을 유지하는 시간
• 커넥션 수락 후 요청 라인이 도착할 때까지 기다리는 시간

WAS 인스턴스 12대 × DB 커넥션 풀 20 개인 서비스에서, DB 의 max_connections 가 200 일 때 예상되는 문제는?

• 정상이다. 12 × 20 = 240 이지만 실제로는 다 쓰지 않는다
• DB 성능만 조금 느려질 뿐 장애로 이어지지 않는다
• 롤링 배포로 인스턴스가 일시적으로 늘어나는 순간 커넥션 한도를 초과해 장애가 난다
• 톰캣이 자동으로 풀 크기를 줄여 준다

-Xms 와 -Xmx 를 같은 값으로 잡는 서버 애플리케이션 관행의 이유는?

• 힙이 커졌다 작아지는 과정에서 생기는 추가 GC 와 지연을 없애기 위해
• JVM 이 필요한 만큼만 잡게 되어 전체 메모리 사용량이 줄기 때문에
• 힙 상한이 고정되면 메모리 부족 오류 자체가 발생하지 않기 때문에
• 기동할 때 힙을 다시 계산하지 않아 기동 시간이 짧아지기 때문에