Apache 인스턴스를 통해 배포된 Laravel 애플리케이션이 있는데, 인스턴스 구성은 다음과 같습니다.
T3A.2xLarge (vCPU = 4, Memory 16 GIB)
아파치 시간 초과를 600초로 늘리고 mpm_prefork
다음과 같이 구성했습니다.
<IfModule mpm_prefork_module>
StartServers 16
MinSpareServers 0
MaxSpareServers 0
MaxClients 16
ServerLimit 256
MaxRequestWorkers 400
MaxConnectionsPerChild 25
</IfModule>
그에 따라 PHP 구성도 변경했습니다.
RDS DB의 max_connection이 600이므로 maxRequestWorker를 400~600으로 구성하지 않으면 오류가 발생합니다 Too Many Connection
.
그러나 이 구성을 사용하면 20번의 램프 업 주기마다 3000명의 사용자를 로드 테스트할 때 504 Gateway Timeout
요청의 절반에 오류가 발생합니다.
그런데 다른 도구와 오류 로그를 보면 오류가 기록되지 않습니다.
구성에 대한 제안 사항이 있습니까?
답변1
이 특정 버그를 찾는 것이 부하 테스트를 수행하는 이유의 90%입니다.
AWS에서 이 작업을 수행하고 있으므로 Application Load Balancer를 사용하고 있다고 가정합니다. 504
일반적으로 애플리케이션이 충분히 빠르게 응답하지 않고 로드 밸런서가 포기한 결과입니다.
이 문제의 원인을 설명하는 로그를 얻을 가능성은 거의 없습니다. 애플리케이션 서버는 모든 것이 괜찮다고 생각했고 로드 밸런서는 기다리기를 포기했을 가능성이 높습니다.
나는 믿는다연결 유휴 시간 초과로드 밸런서의 시간 초과에 영향을 미칩니다. 기본값은 60입니다(서버에 설정한 600보다 훨씬 높음). 하지만 사용자를 그렇게 오래 기다리게 만드는 것은 매우 나쁜 경험이라는 점에 유의하세요.
그렇지 않으면 서버가 왜 그렇게 느리게 실행되는지 조사해야 합니다. 서버 응답 속도를 저하시키는 병목 현상을 찾아야 합니다. 둘 이상이 있을 수 있습니다. 이는 다음과 같을 수 있습니다:
- 시스템 리소스 부족: CPU 및/또는 메모리
- 디스크 IO - 특히 GP2 EBS를 사용하는 경우 - 대신 GP3 사용
- 느린 RDS 응답과 같은 다운스트림 문제 - RDS 등에서 리소스 문제를 찾습니다.
- 잠금 문제. 예를 들어, 애플리케이션이 데이터베이스를 업데이트하는 경우 모든 클라이언트가 경쟁할 수 있습니다. 이 경우 응용 프로그램을 복구해야 할 수도 있습니다.