IIS : 네트워크 연결 속도가 느리기 때문에 시간이 오래 걸리는지 확인하는 방법

http://support.microsoft.com/kb/944884 에 따르면 "네트워크 연결이 느리면 응답이 많거나 응답이 많은 경우 클라이언트에 전송하는 데 걸리는 시간이 예상보다 길어질 수 있습니다."

클라이언트가 "10:03:24에 웹 서버에 요청을 보냈는데 왜 20 초가 걸렸습니까?"라고 말하는 상황이 있습니다. IIS 로그에서도 이것을 볼 수 있지만 서버의 ASP.NET 모듈은이를 100ms로 기록했으며 CPU 및 디스크 카운터는 낮았습니다.

네트워크 연결이 느리기 때문인 것 같습니다. 이것을 어떻게 증명할 수 있습니까?

최신 정보:

1) SOAP 웹 서비스 요청이므로 임베디드 그래픽이 없으며 단일 XML 페이지 결과가있는 HTTP POST 만 있습니다.

2) 또한 클라이언트 측의 네트워크 속도를 조절하여 이것을 재현했으며 증상은 정확히 동일합니다.

3) 문제가 간헐적으로 발생합니다. 이는 동일한 요청이 일반적으로 클라이언트에게는 빠르지 만 때로는 느리다는 것을 의미합니다. 네트워크를 조절하는 것 외에는 이것을 스스로 재생할 수 없습니다. 서버의 ASP.NET 로깅은 항상 빠르다는 것을 보여 주지만 클라이언트가 느리다고 말하면 IIS 로깅은 느리게 표시됩니다.

4) 서버에만 액세스 할 수 있으며 가능한 한 많은 정보를 클라이언트에 제공하여 문제가 서버에 있지 않다는 사실을 인정하고 근본 원인을 찾기 위해 클라이언트에서 어떤 로깅 / 도구를 실행할지 알아야합니다.

클라이언트가 "10:03:24에 웹 서버에 요청을 보냈는데 왜 20 초가 걸렸습니까?"라고 말하는 상황이 있습니다. IIS 로그에서도 이것을 볼 수 있지만 서버의 ASP.NET 모듈은이를 100ms로 기록했으며 CPU 및 디스크 카운터는 낮았습니다.

네트워크 연결이 느리기 때문인 것 같습니다. 이것을 어떻게 증명할 수 있습니까?

그것은 당신의 클라이언트의 브라우저 사이에 떨어 패킷에 대한보고로 시작 하는 모든 상기 웹 페이지 이미지 / 스크립트의 소스 / HTML. 일관된 패킷 손실을 발견하면 네트워크에 과부하가 걸린 링크 일지라도 수정해야 할 것이 있는지 확실히 알 수 있습니다. 패킷 드롭이 느린 네트워크의 유일한 이유는 아니지만 제 경험에서 가장 일반적인 소스입니다. 다른 소스는 잘못 구성된 프록시 또는 캐시 엔진 일 수 있습니다. 슬프게도, 가능한 모든 네트워크 범인을 여기에 나열 할 수는 없습니다.

그러나 실제로 속도 문제가 자체 제어 범위 내에 있으면 사람들은 종종 네트워크를 비난합니다. 가능한 설명 :

• 해당 페이지의 HTML이 잘못 작성되었고 필요한 스크립트를 잘못된 순서로로드한다고 가정하면 거의 모든 리소스가 제자리에 있더라도 전체 페이지가 느리게 렌더링됩니다.
• 페이지가 존재하지 않는 리소스를 기다리는 중입니다. 대기하는 동안 시간이 초과되었습니다.
• 스크립트가 느리게 반복되어 잠시 동안 차단됩니다.
• 캐시 엔진이 이미지를 전달하는 데 시간이 오래 걸림
• CGI가 데이터베이스에서 무언가를 찾고 있으며 조회 자체가 느립니다.
• Google 웹 로그 분석을 사용 하고 있습니다. 페이지 작성 방식으로 인해 속도가 느려집니다.

나는 계속할 수 있지만 요점은 페이지가 느린 이유에 대한 정확한 이유를 알아 내야한다는 것입니다. 결함이있는 네트워크가 가능합니다. 다른 요소가 성능 저하에 기여할 수도 있습니다.

추가 진단 :

• Firefox에서 페이지가 제대로로드되면 Firebug 의 네트워크 탭 이 친구입니다 (적중 F12한 다음 네트워크 탭으로 이동하여 페이지를 다시로드하십시오). Firebug는 페이지로드 방법과 지연 위치에 대한 멋진 폭포 다이어그램을 제공합니다.
• Chrome에서 페이지가 제대로로드되면 유사한 작업을 수행 할 수 있습니다 ( CntlShiftI네트워크 탭을 클릭하고 페이지를 다시로드하십시오).
• 페이지가 IE에서만 지원되는 경우 (btw, HTML 개발자의 부끄러움), 가장 curl느린 방법은 너무 느리게 보이는 것을 찾을 때까지 이러한 각 ASP 페이지 요소를 개별적으로로드 시작하는 것입니다. 느리다.

BTW, Chrome 및 Firefox 예제 는 Debian.org 의 CGI 쿼리를 사용했습니다 . CGI 조회에서 발생하는 지연의 좋은 예입니다.

모든 사람이 실패하면, 당신은 얻을 수 .pcap에서 와이어 샤크 와를 통해 실행 tcptrace; 그러나 tcptrace패킷 덤프를 분석하는 데는 능숙 하지만 문제를 tcptrace단독으로 분리 할 수 ​​있다는 보장은 없습니다 . 진단 사용에 대한 정보는 이 답변 을 참조하십시오 tcptrace.

KB 문서 944884의 결론은 응답을 완료하는 데 필요한 실제 시간이 로그에 정확하게 반영되지 않을 수 있다는 것입니다. 이것이 기사가 네트워크 시간을 언급하는 이유입니다.

증상이 재현 가능한 경우 서버 측 (및 바람직하게는 클라이언트 측)에서 패킷 캡처를 수행하여 클라이언트가 연결을 확인한 실제 시간을 확인합니다.

20 초 지연은 IIS를 w3wp.exe로 다시 시작해야하는데, 이는 사용하지 않을 때 절전 상태가됩니다.