동일한 애플리케이션에 대한 앱 서버 트랜잭션 수(분당 요청 또는 rpm)가 브라우저 트랜잭션 수(분당 페이지 또는 ppm)보다 큰 경우가 많습니다. 모든 페이지가 웹 페이지( API 또는 백앤드 전용 구성 요소 없음)인 사이트라도 기록된 브라우저 페이지 보기보다 2배에서 10배 더 많은 프로세서를 가질 수 있습니다.
해결책
이 문제가 발생할 수 있는 몇 가지 일반적인 이유는 다음과 같습니다.
앱의 모든 페이지를 계측하지 않거나 모든 페이지에서 자동 계측을 사용하지 않습니다.
웹페이지는 text/html 이 아닙니다. (데이터 손상을 방지하기 위해 브라우저는 HTML이 아닌 페이지는 브라우저에서 구문 분석할 의도가 아니기 때문에 이를 소비하지 않습니다.)
백앤드에 대한 일부 요청은 AJAX를 통해 이루어집니다. AJAX 처리량은 브라우저의 AJAX 페이지 에서 별도로 추적됩니다.
일부 요청은 완전히 작동하는 웹 브라우저에서 오지 않습니다. 예를 들어 API 호출이거나 RSS 피드 리더 또는 검색 엔진 인덱서와 같이 JavaScript를 해석하지 않는 장치에서 발생합니다.
일부 요청은 매우 오래된 브라우저(IE 7 이전)에서 발생하거나 쿠키 또는 JavaScript를 차단하는 브라우저에서 발생합니다. 예를 들어 Firefox용 Ghostery 확장은 페이지 로드 타이밍을 차단합니다.
앱 서버와 최종 사용자 사이에 캐시가 있습니다. 캐시된 페이지가 제대로 계측되었는지 여부에 따라 균형이 다른 방향으로 치우쳐 앱 서버보다 브라우저 처리량이 더 많을 수 있습니다.
사용자는 페이지 로드가 완료되기 전이나 window.onload() event 에 도달하기 전에 페이지 밖으로 이동합니다.
New Relic 주간 실적 보고서에는 페이지 조회수가 포함됩니다. 이는 일정 기간 동안 기록된 총 페이지 로드 수입니다. 최종 사용자의 브라우저가 페이지 로드 타이밍을 포함하는 페이지를 로드한 후 JavaScript는 타이밍 데이터를 로드하고 보고합니다. JavaScript가 실행되기 전에 사용자가 페이지를 벗어나면 해당 페이지에 대한 데이터가 전송되지 않고 총 페이지 조회수 보고서에 포함되지 않습니다.