전제:
1. 회사는 첫날 밤(10시간) 동안(한 번에 200개의 동시성) 테스트를 수행했습니다. 56%. 다음날(이 기간 동안 Tomcat이 다시 시작되지 않음) 야간(10h) 테스트도 수행되었지만(한 번에 200 동시성) 처리량이 약 16%로 떨어졌습니다. 환경은 똑같은데 왜 격차가 이렇게 큰 걸까요?
2. 첫날 1,000 동시성 스트레스 테스트를 했을 때 스레드 수는 약 1,000개 이상이었습니다. 그러나 둘째 날 1,000 동시성 스트레스 테스트를 했을 때(이 기간 동안 Tomcat을 다시 시작하지 않았습니다) 스레드 수는 1,000개 이상이었습니다. 이전에는 스레드 수가 700개 이상으로 감소했지만 나중에는 그렇지 않은 이유는 무엇입니까?
위 두 전제에 대해 tomcat에는 어떤 전략이 있습니까? 아니면 jdbc 연결 풀이나 redis 연결 풀이 위 현상을 유발합니까(G1 재활용 메커니즘 사용)?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
이 상황은 복잡합니다. 프로젝트의 실행 환경과 의존하는 다른 서비스에 따라 복잡성이 달라집니다. 스트레스 테스트 환경이 복잡한 경우(즉, 많은 사람들이 서버에서 자신의 작업을 실행하는 경우) 스트레스 테스트 결과가 불안정할 것으로 예상됩니다.
처리량 감소가 발생하면 먼저 병목 현상이 발생한 위치를 확인하세요.
현지 자원이 부족한가요? 기본 리소스에는 주로 CPU, 메모리, 네트워크 대역폭 및 디스크 처리량이 포함됩니다. 이 모든 것에는 관찰과 조사가 필요합니다.
데이터베이스 및 외부 인터페이스의 처리 시간이 너무 긴 등 종속 서비스가 빡빡한지 여부.
이 중 어느 것도 문제를 명확하게 찾을 수 없으면 프로그램 디버깅 단계로 들어갑니다. 각 요청 처리 프로세스 중에 각 단계의 기간을 기록하고 병목 현상이 발생한 단계를 알아내는 것이 매우 정밀하며 필요합니다. 반복적으로 수정하고 기록하고 실행하고 관찰하면 확실히 문제를 찾을 수 있습니다.
문제가 발생하자마자 근거 없는 추측을 하지 마세요. 이때 해야 할 일은 문제를 추적하고 엄격하게 분석하는 것입니다.