spring boot tomcat 파라미터 설정

https://www.cnblogs.com/softidea/p/5750791.html
하나의 socket 은 하나의 스 레 드 [업무 적 의미 의 스 레 드] 에 대응 합 니 다.그러나 이 스 레 드 는 스 레 드 풀 을 사용 하기 때문에 반드시 새로 만 들 것 을 요구 하지 않 습 니 다.
요청: HTTP 분야 의 용어, 통신 은 여전히 socket 연결 입 니 다.

server:
  tomcat:
    uri-encoding: UTF-8
    max-threads: 1000
    max-connections: 20000

max-threads：200； max-connections：10000；
max Threads (최대 스 레 드 수): HTTP 요청 이 웹 서비스 에 도착 할 때마다 tomcat 는 이 요청 을 처리 하기 위해 스 레 드 를 만 듭 니 다. 그러면 최대 스 레 드 수 는 웹 서비스 가 몇 개의 요청 을 동시에 처리 할 수 있 는 지 결정 합 니 다. 기본 값 200.
accepCount (최대 대기 수): 웹 서 비 스 를 호출 하 는 HTTP 요청 수가 tomcat 의 최대 스 레 드 에 도 달 했 을 때 새로운 HTTP 요청 이 왔 습 니 다. 이때 tomcat 는 이 요청 을 대기 열 에 두 었 습 니 다. 이 acceptCount 는 받 아들 일 수 있 는 최대 대기 수 를 말 합 니 다. 기본 100. 대기 열 이 가득 차 면 이 때 새로운 요청 을 다시 하면 tomcat 에서 거부 합 니 다.（connection refused）。
max Connections (최대 연결 수): 이 매개 변 수 는 같은 시간 에 tomcat 가 받 아들 일 수 있 는 최대 연결 수 를 말 합 니 다. 보통 이 값 은 max Threads + acceptCount 보다 큽 니 다.

스 레 드 를 늘 리 는 데 비용 이 듭 니 다. JVM 에서 기본 적 인 상황 에서 새 스 레 드 를 만 들 때 크기 가 1M 인 스 레 드 스 택 을 분배 하기 때문에 더 많은 스 레 드 가 더 많은 메모리 냄새 를 냅 니 다.

더 많은 스 레 드 는 더 많은 스 레 드 컨 텍스트 전환 비용 을 가 져 올 것 이다.

tomcat 에 게 들 어 오 는 요청 (request) 은 요청 이 끝 날 때 까지 스 레 드 가 필요 합 니 다. 현재 사용 가능 한 요청 처리 스 레 드 보다 동시에 들 어 오 는 요청 이 많 으 면 설정 의 최대 스 레 드 수 (maxThreads 속성 값) 에 도달 할 때 까지 추가 스 레 드 가 생 성 됩 니 다.... 더 많은 요청 을 동시에 받 으 면 처리 할 수 없 는 요청 은 커 넥 터 가 만 든 ServerSocket 에 최대 설정 값 (acceptCount 속성 값) 에 도달 할 때 까지 쌓 입 니 다. 더 이상 요청 할 수 있 는 자원 이 있 을 때 까지 connection refused 오류 가 발생 합 니 다.
여기 서 우리 가 관심 을 가 지 는 것 은 tomcat 가 동시에 처리 할 수 있 는 요청 수 와 요청 응답 시간 입 니 다. 커 넥 터 요소 의 max Threads 와 acceptCount 속성 이 직접적인 영향 을 미 치 는 것 이 분명 합 니 다. acceptCount 값 이 얼마 든 max Threads 는 실제 동시에 처리 할 수 있 는 요청 수 를 직접 결정 합 니 다. max Threads 가 어떻든 acceptCount 는 얼마나 많은 요청 을 기다 릴 수 있 는 지 를 결정 합 니 다. 그러나,요청 을 즉시 처리 할 수 있 든 대기 구역 에 넣 어야 하 든 tomcat 가 먼저 이 요청 을 받 아들 여야 합 니 다 (즉, client 의 연결 요청 을 받 아들 이 고 socketchannel 을 만 듭 니 다). 그러면 tomcat 가 동시에 만 들 수 있 는 연결 수 (max Connections 속성 값) 도 동시에 처리 할 수 있 는 요청 수 에 영향 을 줄 수 있 습 니 다.
홈 페이지https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#common- application - properties, 모든 설정 정 보 를 볼 수 있 습 니 다.
공식 spring boot 학습 절차:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-configure-tomcat
참고:https://blog.csdn.net/kouwoo/article/details/83898788
https://blog.csdn.net/u012661248/article/details/80748814
https://www.cnblogs.com/softidea/p/5750791.html
압력 테스트 에 대한 설명 은 일반적으로 두 부분 을 포함한다. 즉, 동시 다발 사용자 수 와 총 요청 수, 즉 얼마나 많은 사용자 가 동시에 서버 에 얼마나 많은 요청 을 보 내 는 지 모 의 하 는 것 이다.
요청 성질 은 요청 한 URL 이 대표 하 는 자원 에 대한 설명 입 니 다. 예 를 들 어 1KB 크기 의 정적 파일 이나 10 회 데이터베이스 조 회 를 포함 하 는 동적 내용 등 입 니 다.
1. 동시 다발 사용자 수
동시 다발 사용자 수 는 어느 순간 서버 에 요청 한 사용자 수 를 동시에 보 내 는 것 을 말한다.
100 명의 사용자 가 동시에 서버 에 10 번 씩 요청 하면 1 명의 사용자 가 서버 에 1000 번 연속 요청 합 니 다. 두 개의 효과 가 같 습 니까?
한 사용자 가 서버 에 1000 번 연속 으로 요청 하 는 과정 에서 언제든지 서버 의 네트워크 카드 는 캐 시 구역 에서 해당 사용자 의 1 개 요청 만 받 고 100 명의 사용자 가 동시에 서버 에 각각 10 번 요청 하 는 과정 에서 서버 네트워크 카드 는 버퍼 구역 에서 최대 100 개의 대기 처 리 를 요청 하 는 것 이 서버 의 압력 이 더 큰 것 이 분명 하 다.
어떤 웹 서버 가 얼마나 많은 병발 수 를 지원 할 수 있 는 지 를 말 하 는 경우 가 많다. 그 밖 에 문맥 이 없 기 때문에 많은 사람들 이 종 잡 을 수 없다. 사람들 은 병발 사용자 수 와 삼투 율 을 헷 갈 리 게 한다. 그들 은 결코 같은 일이 아니다.
한 서버 는 최대 몇 개의 동시 다발 사용자 수 를 지원 합 니까?
우 리 는 이 카운터 가 지원 하 는 최대 병발 수 는 10 이 라 고 말 할 수 있다. 마침 이 병발 수 에서 카운터 업 무 는 매우 성공 적 으로 전개 되 었 기 때문이다. 고객 들 은 서비스 시간 에 매우 만족 하고 이때 업무 처리 횟수 를 대표 하 는 카운터 의 삼투 율 도 비교적 높 아 백화점 과 고객 들 이 윈 윈 을 이 루 었 다.
이 를 통 해 알 수 있 듯 이 일반적으로 말 하 는 최대 병발 수 는 일정한 이익 전제 가 있다. 그것 은 바로 서버 와 사용자 쌍방 이 기대 하 는 최대 수익 이다. 서버 는 높 은 병발 수 와 높 은 삼투 율 을 지원 하고 자 한다. 사용 자 는 그렇게 많 든 적은 시간 을 기다 리 거나 더 빠 른 다운로드 속 도 를 얻 기 를 원한 다.
따라서 최대 병발 수의 의 미 는 서버 의 적재 능력 을 파악 하고 사용자 규모 와 결합 하여 적당 한 확장 방안 을 고려 하 는 데 있다.
같은 도 메 인 이름 의 URL 에 대한 동시 다운로드 수 는 최대 제한 이 있 습 니 다. 브 라 우 저의 차이 점 을 구체 적 으로 제한 합 니 다. 실제 사용 자 는 서버 에 두 개 이상 의 동시 다발 사용자 의 압력 을 가 져 올 수 있 습 니 다. 일부 훌륭 한 사용 자 는 브 라 우 저의 동시 다발 수 제한 을 수정 할 수 있 습 니 다.
참고:https://www.cnblogs.com/cnmenglang/p/6272762.html