IIS7 ASP.NET 응용 프로그램-2 개의 동일한 응용 프로그램 풀에있는 2 개의 동일한 응용 프로그램

가상 디렉터리 (응용 프로그램으로)에 설치되고 자체 응용 프로그램 풀에서 호스팅되는 ASP.NET (v4.0) 웹 응용 프로그램이 있습니다. 앱의 각 인스턴스에 대해 (예 : 고객 당) 반복됩니다.

앱 풀은 클래식이 아닌 통합 모드이며 LoadUserProfile이 true로 설정되어 있습니다. 그렇지 않으면 기본 설정입니다.

각 인스턴스에는 현재 자체 코드 / 구성 사본이 있으며 자체 데이터 폴더 (기본 파일 읽기 / 쓰기)가 있습니다.

이 앱의 인스턴스 1 개가 제대로 실행됩니다 (비교에 사용되는 작업은 ~ 4 초 소요). 다른 모든 인스턴스는 동일한 작업을 위해 10-25 초에서 느리게 실행됩니다.

느린 인스턴스를 "가장 빠른"앱 풀로 옮기면 인스턴스가 생겨납니다. 더 빠른 인스턴스를 더 느린 앱 풀로 이동하면 해당 인스턴스가 크롤링 속도가 느려집니다.

앱 풀은 처음과 같은 방식으로 수동으로 생성되었습니다. 나중에 Powershell 복사 루틴을 사용하여 더 빠른 앱 풀의 정확한 사본과 동일한 동작을 보장했습니다. apppool.config 파일을 비교하면 가상 디렉터리 할당이 동일한 파일임을 알 수 있습니다.

내가 말할 수있는 한 차단되는 공유 리소스가 없으며 수행 가능한 응용 프로그램 풀을 종료하고 다시 시작하여 테스트했습니다 ... 느린 속도는 여전히 느리다가 앱 풀을 다시 시작할 때 마지막) 여전히 빠릅니다 ...

문제를 더 격리시키기 위해 호스트 시스템에서 Wireshark (또는 선택한 다른 패킷 분석기)를 두 세션 동안 실행하는 것이 좋습니다. 내가 만들고있는 가정은 각 앱 풀에 고유 한 IP가 할당되었거나 고유 한 포트가 있다는 것입니다.

먼저 빠른 앱 풀의 IP : 포트를 필터링하여 기본 성능을 얻으십시오. "정상"조건에서 앱을 오가는 트래픽이 어떻게 보이는지 확인하십시오.

두 번째 실행에서는 느리거나 응답이없는 앱 풀에서 트래픽을 캡처해야합니다. 모든 네트워크 라우팅 등이 상자에 맞으면 한 방향으로 반복 된 요청이 표시 될 것입니다. 다른 곳에서 앱에 대한 가능성이 높지만 앱이 다른 서버에 많은 요청을하는 경우 트래픽이 발생할 수 있습니다. 입구 대신에 출구가 무겁습니다.

이 테스트는 문제가 앱 내에 있는지 또는 TCP / IP 관련 문제인지 여부를 알려줍니다. 이로 인해 통신 요청이 적거나 없어서 앱 요청이 시간 초과됩니다.

테스트의 타임 스탬프를 서버의 이벤트 로그 및 (해당되는 경우) 추적 싱크 로그와 연관 시키십시오. 그러면 문제점에 대한 정보를 얻을 수 있습니다.

FRT (실패한 요청 추적)가이를 추적하는 가장 좋은 도구입니다. 파이프 라인과 각 단계를 완료하는 데 걸린 시간이 표시됩니다. 그것은 그것이 asp.net 부분 내에 있는지 아니면 IIS 파이프 라인 자체 내에 있는지를 지적해야합니다.

FRT를 설정하려면 사이트 수준의 IIS에서 http 상태 범위가 200-999 인 FRT 규칙을 만들고 FRT를 활성화해야합니다 (작업 창과 별도의 단계 임).

그런 다음 문제를 재현하고 생성 된 파일 (% SystemDrive % \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid})을 확인하십시오. Internet Explorer에서 엽니 다.

IIS가 명백한 이유없이 오랜 시간 지연되는 경우 일반적으로 외부 서비스가 시간 초과 될 때까지 대기하고 있음을 의미합니다. 그렇다면 다른 접근 방식을 시도합니다. 이 문제에 대해서는 Windows 또는 Linux의 모든 사항에 해당됩니다. 이러한 상황에서 가장 먼저 의심되는 것은 항상 네트워크 이름 확인 구성입니다. 결백 할 때까지 유죄입니다.

한 명의 사용자가 중복 된 사이트 중 하나를 방문하여이를 다시 만들 수 있습니까? 10-20 초의 응답 시간을 다시 만들 때 CPU와 디스크가 무엇을하고 있는지 아는 것이 좋습니다. 10-20 초 동안 많은 일이 일어나지 않는 경우 바인딩 이름과 바인딩 이름의 이름 확인을 확인해야합니다. CPU 또는 디스크가 씹 히면 어떤 프로세스가 너무 열심히 작동하는지와 그 이유를 알아야합니다.

조사 결과를 게시하십시오. 궁금합니다.

추신 : 나는 또한 이름 확인과 사용중인 인증 서비스에 대한 액세스를 확인합니다. 예를 들어 도메인 서버를 참조해야하는 경우 목록의 첫 번째 DNS 서버가 도메인의 DNS 서버인지 확인하십시오.

이것은 해결책이 아니지만 해결을 위해 노력할 것입니다.

1. 유지 관리 시간 동안 IISRESET을 실행하거나 응답하지 않는 앱 풀에 속하는 W3WP를 종료하십시오.

2. 응용 프로그램을 시작

3. 응답이없는 동안 느린 앱 풀에 속하는 W3WP의 덤프 파일을 가져옵니다. 중 하나를 사용하여 프로세스 탐색기 덤프 파일을 만들거나 작업 관리자를

4. C : \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX에서 mscordacwks.dll 및 mscorwks.dll을 가져옵니다.

5. 다운로드 할 수있는 곳에서이 파일을 압축하여 업로드하십시오.