JSF 비즈니스 스레드 풀의 크기 구성에 대해 이야기

1. 소개

JSF 비즈니스 스레드 풀은 JDK의 스레드 풀 기술을 사용하며 기본적으로 캐시 모드를 채택합니다(코어 스레드 수는 20개, 최대 스레드 수는 200개). 또한 고정 스레드 크기 모드도 제공되며 두 모드 모두 요청 대기열 크기를 설정할 수 있습니다.

이 기사의 목적은 단순화된 시나리오("단일 서비스 애플리케이션")의 로드 테스트를 통해 "JSF 비즈니스 스레드 풀 크기 구성"에 대한 벤치마크 결과를 제공하고 일반적으로 적용 가능한 몇 가지 결론을 도출하는 것입니다.

이 기사의 대상 독자에는 JSF 스레드 크기를 합리적으로 구성해야 하는 스트레스 테스트 엔지니어, 개발, 배포, 운영 및 유지 관리 엔지니어와 설계자가 포함됩니다. 이 기사에서는 JSF 서버의 다른 구성 항목을 다루지 않으며 "복합 서비스 애플리케이션"의 합리적인 구성에 대해서도 논의하지 않습니다. 이 글에서 제시한 결론은 스트레스 테스트 케이스 설계나 비즈니스 스레드 풀의 크기 평가를 위한 기본 방법을 설계할 때 참고자료로 활용하면 실제로 JSF 비즈니스 스레드 풀의 크기를 합리적으로 구성할 수 있다. JSF 비즈니스 스레드 풀 크기의 합리적인 구성은 충실도가 높은 로드 테스트 결과를 기반으로 해야 한다는 점에 유의해야 합니다.

"단일 서비스 애플리케이션"은 애플리케이션에 제공된 인터페이스가 하나만 포함되어 있고 인터페이스에 메서드도 하나만 포함되어 있음을 의미합니다.

"복합 서비스 애플리케이션"은 제공되는 여러 인터페이스를 포함하는 애플리케이션 또는 여러 메소드를 포함하는 인터페이스를 의미합니다.

2. 테스트 케이스 설명

이번 벤치마크 테스트에서는 USF3.0 권한 시스템을 선택하여 이를 단일 서비스 제공자로 맞춤화했으며, 제공자의 한 가지 방식만 테스트했기 때문에 '단일 서비스 애플리케이션'으로 볼 수 있다. 테스트에서는 CPU를 벤치마크 테스트의 핵심 자원으로 사용하며, JVM 가비지 컬렉터의 영향을 고려하여 간단한 테스트 데이터를 사용하여 서비스에 대한 각 호출의 일관성을 보장하고 YGC가 FGC의 영향 없이 규칙성(즉, 고정된 호출량으로 인해 한 번에 30+ms의 YGC가 발생함).

테스트 케이스 설계에서는 테스트 프로세스 중에 서비스 가용성 비율이 100%에 도달하도록 모든 종속 서비스 리소스가 무제한입니다. 우리의 핵심 성과 지표는 TP99입니다. 즉, 서비스 응답 시간의 99%가 10ms 미만이어야 합니다.

다양한 스레드 풀 모드에서의 성능을 테스트하기 위해 JSF 스레드 풀의 캐시 모드와 고정 모드를 사용했으며, 각 모드에 대해 여러 세트의 테스트를 수행하여 시스템의 최대 부하 조건을 확인했습니다.

테스트 적용 : USF3.0 권한 시스템(맞춤형 처리)

테스트 서비스 : com.jd.susf.service.api.SusfPermissionService#findUserInfo는 사용자 정보를 기반으로 Redis의 데이터 일부를 쿼리하여 반환되는 서비스입니다.

하드웨어 구성 : 단일 4C 8G

테스트 방법 : Forcebot 시스템은 캐시 및 고정 모드에서 JSF 비즈니스 스레드 풀에 대한 시스템 부하 테스트를 수행하기 위해 사다리 압력 방법을 채택했습니다.

SLA 요구 사항 공식화 : 서비스 응답 시간 <10ms의 TP99

참고: USF3.0 권한 시스템을 사용자 정의하고 서비스 공급자의 구성 데이터를 조정했으며 com.jd.susf.service.api.SusfPermissionService만 유지했습니다.

3.테스트 결과 및 분석

3.1 캐시된 스레드 풀의 시스템 부하

그림: 다양한 동시 사용자 수(1-200)에서 JSF 기본 스레드 풀(캐시됨, 스레드=200)의 시스템 로드 다이어그램

동시 사용자 수 TP99 처리량TPS CPU 사용률(%)
1~23 <8ms 선형 성장 선형 성장
24 8ms 6553 99.62
25 11ms 6607 99.83
26~79 빠른 성장 느린 성장 99+
80 74ms 6928 99.82
81~199 천천히 증가하다 천천히 쇠퇴하다 99.82
200 99ms 6230 99.94

요약: 기본 JSF 스레드 풀 구성에는 큰 위험이 있습니다. 시스템은 최대 24개의 동시성을 지원할 수 있으며, 24개를 초과하는 동시성에 도달하면 SLA를 충족할 수 없습니다.

3.2 고정 스레드 풀(큐)의 시스템 부하

그림: 동시 사용자 수(1-50)가 다른 JSF 고정 스레드 풀(고정+큐)의 시스템 로드 다이어그램

JSF 비즈니스 스레드 수 지원 가능한 최대 동시 사용자 수 TP 가치 (50/90/99/999) 처리량(TPS) CPU 최대 사용률(%)
4 11 18/7/8/10 1531 27.67
8 25 8/8/10/18 3113 46.45
16 50 8/8/10/21 6228 87.97
20 23 15/3/4/10 6409 99.92
24 22 3/4/7/15 6178 99.86
25 22 3/4/6/15 6182 98.83

표: JSF 고정 비즈니스 스레드 풀(고정+큐)은 TP99<10ms의 시스템 최대 로드(최대 동시 사용자 수)를 충족합니다.

요약:

① 고정 스레드 모드에서는 CPU 사용률에 상한이 있습니다.

② 큐를 사용하면 시스템의 동시성 지원이 효과적으로 증가하고 처리량도 향상될 수 있습니다. 그러나 작업이 대기열에서 기다리고 있기 때문에 서비스의 응답 시간은 "밀물이 모든 배를 들어 올립니다"라고 나타나며 일정한 위험이 있습니다.

3.3 고정 스레드 풀의 시스템 부하

그림: JSF 고정 스레드 풀(고정) 모드에서 시스템에 최대 동시 사용자 수가 있을 때 시스템 로드

JSF 비즈니스 스레드 수 동시 사용자 수 TP99 처리량(TPS) CPU 최대 사용률(%)
4 4 5 1063 20.26
8 8 5 2216 36.62
16 16 6 4262 68.56
20 20 5 5550 86.22
24 24 8 6711 99.62
25 25 16 6644 98.77
26 26 19 6744 99.93

요약: 고정 스레드 풀(고정)의 성능을 기반으로 CPU 리소스의 전체 활용도 균형을 맞추고 SLA 요구 사항을 충족하려면 합리적인 스레드 수를 설정해야 합니다. 스레드 수가 너무 적으면 오류가 발생합니다. CPU 자원 낭비가 발생하며, 스레드 개수가 너무 많으면 불가능합니다.SLA를 만나보세요.

4 결론

테스트 결과와 데이터 분석을 바탕으로 다음과 같은 결론을 내립니다.

  • JSF 스레드 풀의 기본 구성은 동시성이 높은 시나리오에서는 위험합니다 . 온라인 프로덕션 환경에 JSF 서비스가 있는 서버는 200개의 스레드로도 SLA를 충족할 수 없습니다. 최대 200개의 스레드로 스레드 풀을 구성하면 동시성이 높은 시나리오에서 서버가 과부하될 위험이 있습니다. 스레드 풀 크기의 적절한 구성은 충실도가 높은 로드 테스트를 통해 이루어져야 합니다.
  • 충분한 수의 스레드가 리소스(CPU) 활용을 보장할 수 있습니다 . 비즈니스 유형 서비스는 일반적으로 특정 IO 작업(네트워크, 디스크 등)이 있으며 스레드 실행 중에 대기가 발생합니다. CPU 활용도가 높지 않으며 동시성이 필요합니다. 스레드 수를 늘리고 더 많은 스레드가 CPU 할당에 참여하도록 허용해야만 CPU 사용률을 향상시킬 수 있습니다. 서비스의 IO 작업이 많을수록 대기 시간이 길어지고 필요한 동시 스레드도 늘어납니다. IO 작업이 포함된 비즈니스 서비스의 경우 부하 테스트를 위한 스레드 수는 2N(N은 서버의 CPU 코어 수)부터 시작할 수 있습니다.
  • 과도한 스레드 수는 시스템의 SLA만 감소시킵니다 . 스레드 수가 이미 CPU의 100%를 활용할 수 있는 경우 스레드 수를 늘리면 스레드가 충분한 CPU 할당을 얻을 수 없으므로 이에 대한 응답은 다음과 같습니다. 서비스 시간이 늘어납니다. 특정 범위 내에서 TP99는 여전히 SLA 요구 사항을 충족할 수 있으며 시스템 처리량도 약간 증가합니다. 스레드 수를 계속 늘리면 TP99가 시스템 요구 사항을 충족할 수 없으며 시스템 처리량이 감소하기 시작합니다.
  • 고정된 수의 스레드는 시스템이 감당해야 하는 로드 용량을 보호할 수 있습니다 . 고정된 수의 스레드는 시스템의 CPU 사용률을 특정 로드 범위로 제한하고 시스템의 안정적인 작동을 보호하며 응답 시간을 보장할 수 있습니다. TP99이지만 시스템의 동시성 기능도 제한합니다. 대기열 크기를 적절하게 설정하면 시스템의 동시성을 높일 수 있으며 시스템 TP99에는 영향을 미치지 않습니다. 그러나 서비스의 전체 응답 시간이 증가하고 불안정한 변경이 발생하므로 위험합니다.
  • CPU를 100% 높은 부하로 실행 : 일반적으로 서비스의 외부 SLA 약정은 ​​일반적으로 서비스의 실제 성능보다 높으며 이는 인프라 및 종속 서비스의 불안정성을 고려하기 때문입니다. 따라서 CPU가 100%에 도달하더라도 외부 응답 시간 TP99 약속에 영향을 주지 않고 스레드 수를 일정량만큼 늘릴 수 있습니다. 이는 시스템의 동시성 기능을 향상시킬 수 있습니다. 시스템이 높은 부하에서 실행될 수 있지만 시스템의 신뢰성을 향상하려면 추가 안정성 테스트를 수행해야 합니다.

요약하자면, 스레드 풀 크기의 합리적인 구성은 비즈니스 요구 사항 및 시스템 리소스 조건을 기반으로 평가 및 테스트되어야 하며, 시스템의 안정적인 작동을 보장하고 사용자 SLA를 충족하기 위해 합리적인 버퍼 공간을 확보해야 합니다.

5. 부록

부록 1: 통계 지표 및 용어 설명

동시 사용자 수 : 동시에 요청을 시작한 사용자 수입니다.

TP 값(50/90/99/999) : 클라이언트의 TP 값, 단위 ms, 데이터는 Forcebot에서 가져옵니다.

처리량 TPS : 데이터는 Forcebot에서 가져옵니다.

CPU 사용률(%) : 데이터는 PFinder에서 가져옵니다.

JSF 비즈니스 스레드 수 : JSF 비즈니스 스레드 풀의 스레드 수입니다. 예: <jsf:server id="jsf" 프로토콜="jsf" threadpool="fixed"  스레드 ="16" />

고정/캐시 : JSF 비즈니스 스레드 풀의 스레드 풀 유형(예: <jsf:server id="jsf" 프로토콜="jsf"  threadpool="fixed"  스레드="200"/>)

마지막으로: 아래 완전한 소프트웨어 테스팅 비디오 튜토리얼이 편집되어 업로드되었습니다. 필요한 친구는 스스로 얻을 수 있습니다. [100% 무료 보장]

소프트웨어 테스팅 인터뷰 문서

고임금 일자리를 찾으려면 공부를 해야 합니다. 다음 면접 질문은 알리바바, 텐센트, 바이트 등 1위 인터넷 기업의 최신 면접 자료이며 일부 바이트 상사들이 권위 있는 답변을 제공했습니다. 이 세트를 마친 후 면접정보를 바탕으로 누구나 만족스러운 일자리를 찾을 수 있다고 믿습니다.

추천

출처blog.csdn.net/wx17343624830/article/details/132830463