APM은 요청이 프로덕션 시스템에 들어간 후 애플리케이션에 도달하기 전의 시간을 추적합니다. 우리는 귀하의 요청의 수명주기 중 이 부분을 request queuing 이라고 부릅니다. 프로덕션 시스템의 세부 사항에 따라 이 시간 측정에는 입장을 요청하는 실제 대기열이 포함될 수도 있고 포함되지 않을 수도 있습니다. 또한 다른 기능(예: 로드 밸런싱 또는 내부 네트워크 지연 시간)을 나타낼 수도 있습니다.
요청 대기열을 사용하여 확장 문제 식별
요청 대기열에 소요된 시간을 추적하면 특정 유형의 성능 및 확장 문제를 식별하는 데 유용합니다. 예를 들어:
- 프런트엔드 웹 서버가 애플리케이션 작업자를 사용할 수 있을 때까지 기다리는 데 시간이 걸리는 경우
- 배포 또는 재시작 후 애플리케이션 작업자를 워밍업하는 데 추가 시간이 소요되는 경우
요청 대기열을 보고하려면 뉴렐릭 에이전트 와 서버를 구성해야 합니다. 그러면 웹 트랜잭션에 대해 선택한 애플리케이션의 Requests time 차트(APM의 Applications 목록에서 앱 선택)와 사용자 인터페이스의 다른 위치에 정보가 표시됩니다. 차트의 범례는 요청 대기열을 나타내는 색상을 나타냅니다.
Apdex 계산
요청 대기열은 브라우저가 콘텐츠를 요청한 시점부터 콘텐츠를 수신할 때까지의 시간입니다. Apdex 점수는 이러한 계산을 반영하므로 요청 대기열 시간을 별도로 보고할지 여부를 선택할 수 있습니다. 자세한 내용은 에이전트 구성 을 참조하십시오.
시계 왜곡
프런트엔드 웹 서버(예: Nginx)와 애플리케이션이 동일한 물리적 서버에 상주하지 않는 경우 보고된 요청 대기열은 클럭 스큐의 영향을 받을 수 있습니다. NTP는 서버 시계를 동기화 상태로 유지하는 훌륭한 방법을 제공합니다. 그러나 그들은 여전히 서로 상대적으로 표류합니다. New Relic 에이전트는 프런트엔드 서버에서 설정한 타임스탬프에 의존하기 때문에 해당 서버의 시계가 앱 서버의 시계와 밀접하게 동기화되지 않은 경우 요청 대기열을 과도하게 또는 과소 보고할 수 있습니다.
이것은 기능의 주요 문제처럼 보일 수 있습니다. 그러나 클럭 스큐로 인해 보고된 요청 대기열이 갑자기 급증하지 않을 것입니다. 갑작스러운 스파이크는 일반적으로 앱이 다시 시작되거나 요청이 과부하될 때 발생합니다. 우리의 경험에 따르면 요청 대기열 보고는 실제 성능 문제를 식별하는 데 유용할 수 있지만 이 데이터를 해석할 때는 클럭 스큐를 고려해야 합니다.