응용 프로그램의 백엔드 성능을 일부 향상 시켰으며 GUI 최종 사용자에게 이점을 보여주기 위해 Trace.axd 페이지를 사용했습니다 타이밍. (프런트 엔드는 .Net 1.1이고 백엔드는 웹 서비스를 통해 연결된 Java입니다.)ASP.NET 추적에서 정보를 늘리는 방법
그러나 이러한 타이밍은 이전 백엔드와 새 백엔드간에 차이가 없음을 보여줍니다.
백엔드에 중단 점을 넣고 30 초 동안 요청을 보냄으로써 Trace.axd에서 POST가 3ms 걸리고 GET이 4 초가 걸린다는 것을 알 수 있습니다. 나는 약 26 초를 놓치고있다 ...
POST는 성능 향상이 있어야하지만 추적 페이지의 타이밍은 리턴하는 데 걸리는 시간이 아니라 요청을 보내는 데 걸리는 시간 만 포함 된 것 같다. .
전체 요청을 포함하도록 추적에서 정보의 입도를 줄이는 방법이 있습니까? 또는 필요한 측정을 수행 할 다른 방법이 있습니까?
.NET에서 요청하는 방법을 잘 모르겠지만 어딘가에 HttpWebRequest가 있다고 가정합니다. 응답 헤더를받은 즉시 HttpWebRequest.GetResponse() 반환하도록 기대하고 싶습니다. 그렇게하면 나머지 응답이 다운로드되는 동안 큰 응답의 시작을 처리 할 수 있습니다. 추적 메시지가 GetResponse 호출 직전과 직후 인 경우 백엔드의 전체 실행 시간을 볼 수 없습니다. 응답을 닫은 직후 추적 메시지를 추가 할 수 있습니까?
brakpoint에서 소비 한 모든 시간이 추적 출력에 표시되지 않는 것이 이상합니다. 총 시간 열을 확인하여 요청에 사용한 시간과 일치하는지 확인 했습니까? 열 중 하나에는 이전 추적 문 이후로 보낸 시간 만 표시된다는 점을 잊지 마십시오.
추적 출력에서보다 세부적인 데이터를 원하는 경우 직접 추가 할 수 있습니다. TraceContext 클래스에는 출력에 행을 추가하는 Warn 및 Write라는 두 가지 메서드가 있습니다 (warn은 빨간색으로 추가 함).
TraceContext는 모든 페이지 또는 컨트롤에서 액세스 할 수 있습니다. this.Trace.Warn() 또는 this.Trace.Write()를 사용하면됩니다 (또한 HttpContext 클래스를 통해 액세스 할 수 있다고 생각합니다).
비정상적인 문제가 아닙니다. 문제는 POST가 전송되는 지점까지의 기본 추적 로그이며 응답 시간은 포함되지 않습니다. – fiddlesticks
실제로, 추적은 페이지 내용을 와이어를 통해 보내는 데 걸리는 시간을 표시하지 않습니다.이를 확인하려면 Fiddler와 같은 도구가 필요하며 IIS 프로파일 도구를 찾아야합니다. –
좋아요, 나는 결국 내가 원하는 것을 얻었습니다. 문제는 IIS 추적에 POST가 반환하는 데 걸리는 시간이 포함되지 않는다는 것입니다.
Trace.Write()를 사용하여 추적 로그에 사용자 지정 항목을 추가하고 Trace.Write (문자열 범주, 문자열 메시지)를 사용하여 범주를 추가 할 수도 있습니다.
POST가 완료된 후 실행되는 코드에서 Trace.Write() 호출을 추가하면 더 좋은 그림이됩니다.
그래도 사용자 정의이므로 이상적이지 않습니다. 가능한 한 POST주기가 끝날 때까지 넣어 두는 것이 좋습니다.
HttpWebRequest 질문이 아닙니다. ASPX 질문과 비슷합니다. –
예, 명시적인 HttpWebRequest가 없습니다. Microsoft WS 마법 만 – fiddlesticks
WS 마법이 어떻게 요청을했다고 생각합니까? 그러나 웹 서비스 호출이 리턴되기 전에 전체 응답 스트림을 읽으므로 기대할 수있는 것이 맞을 것입니다. – stevemegson