호스팅 Azure 웹 응용 프로그램(ASP.NET MVC)은 10 분마다 차가워지고로드하는 데 10-20 초가 걸립니다.




asp.net mvc5 (5)

  1. 배포와 로컬을 구분하십시오. 응용 프로그램이 로컬 환경에서 완벽하게 실행되는 경우 Azure로 넘어갈 때 다른 상황이 발생합니다. 무언가를 해결하는 데는 많은 시간이 걸립니다.
  2. 정적 리소스 (스크립트, 스타일 등)는 첫 번째 요청에서 브라우저에 의해 자동 캐시되므로 나중에 요청할 때 문제가 발생하지 않아야합니다.
  3. "Render"메서드가 문제를 제공한다는 것을 알고 있기 때문에 복잡한 중첩 계산과 브라우저 DOM 조작이 발생하고있는 것처럼 보입니다. 그러나이 문제가 로컬에서 발생하지 않는 경우 외부 리소스에 대한 렌더링 호출이 있는지 확인하고 차단 호출이 발생했는지 확인하십시오 (Ajax 또는 서버 측 비동기 호출이 많이 필요할 수도 있음).
  4. 가능한 리팩토링이 필요할 수 있지만 (작은 스택을 가지며 스레딩 / 비 블로킹 IO 사용이 가능할 수 있음) 코드를 참고하여이를 제안해야합니다.

페이지로드 이벤트 및 이후의 모든 통화를 공유하십시오. 또한 DOM 핸들링과 함께 뷰가 렌더링되는 방법도 있습니다.

나는 Azure Web App에 매우 이상한 문제가 있으며, 나는 그것에 상당히 좌절하고있다.

우리는 앱을 사용할 때 매우 빠르고 반응이 빠르다는 것을 경험하지만, 약 10 분 동안 사용하지 않으면 매우 추운 시작을합니다 (~ 10-20 초). 이 콜드 스타트는 데이터베이스와 관련된 경우에만 발생합니다. 언제 우리가 웹 애플 리케이션을 공개 같은 비트.

시도

Azure에서 Application Insights를 사용하여 5 분마다 ping을 설정했습니다.

특이 치는 항상 배치 (배치 슬롯을 사용하지 않음)에 의해 발생합니다. 그러나이 로그인 페이지는 데이터베이스를 호출하지 않으므로이 데이터에서 "콜드"시작을 볼 수 없습니다.

응용 프로그램 설정은 견고해야합니다. 우리의 웹 앱은 북유럽에서 Always on :

우리는 전체 설정을 새로운 리소스 그룹 / 앱 서비스 계획으로 이동하여 문제가 다른 앱과 얽혀 있는지 확인했습니다. 새 앱 서비스 계획은 Standard 1 small 로 문제가되어서는 안됩니다. 우리의 소비를 보면 나는 걱정하지 않으며 아마도 문제를 해결 한 후에 할 작은 서비스를 시도 할 수도 있습니다.

우리의 SQL 데이터베이스는 북유럽에서 호스팅되기도합니다 (이전에 실수로 인해 수십 억 번 확인 된 위치).

앱 서비스와 마찬가지로 문제를 일으키지 않는 "너무 큰"하드웨어 (표준 S0 : 10 DTU)를 선택했습니다. 그 사용법은 엄청나게 낮습니다.

우리는 계속해서 배치 (Azure 메뉴의 Deployment options )를 사용하지만, 배치를 보면 계속해서 뭔가를 배치해서는 안됩니다 :

응용 프로그램의 좌절감은 작동 할 때 반응이 좋습니다. 웹 앱에 평균 응답 시간이 표시되는 것처럼 모든 페이지가 "따뜻하게"로드 될 때처럼 초 단위로로드됩니다.

그러나이 숫자는 우리 (또는 사용자)가 앱을 사용할 때 명백히 잘못되었습니다. 여기서 우리는 매우 자주 처음으로 + 10-20 초의 부하를 경험합니다.

누구든지 아이디어가 있습니까? 어떤 힌트? 내가 얼마나 감사 할 지 모르겠다.

편집 및 업데이트 1 :

좀 더 테스트를하기로 결정했습니다. 이제 다른 페이지를 호출하여 문제를 보여주는 실제 데이터를 얻을 수있었습니다. 아이러니하게도이 페이지는 데이터베이스를 호출하지 않으므로 이것이 데이터베이스 문제라고 생각했지만 실제로는 그렇지 않습니다. 여기서 도전 해보십시오 (추세는 +24 시간 지속됨).

정확히 10 초 정도 안정되어있는 것이 이상합니다. 그리고 그 추세는 매 10 분에서 20 분이 아니라, 매 5 분마다 가깝습니다.

편집 및 업데이트 2 :

나는 더 많이 파고 있었다. 매우 흥미로운 몇 가지 통찰력이 있습니다. 편집 1에서 "느린"11 초 통화는 동부 미국 및 한 끝점 ( http://prntscr.com/jcv69w )에서만 발생합니다.

내가 발견 한 가장 흥미로운 것은 다음과 같다.

응용 프로그램 자체에는 캐싱이 없습니다. Entity Framework를 사용하여 일부 캐싱을 사용한다고 가정하지만 그게 전부입니다.

우리 앱에 로그인하여 Chrome에서 클릭했습니다. 나는 이미 방문한 페이지가 즉석에서 (DB의 데이터로) 보여 주지만, 새 페이지를 열면 느리게로드된다는 것을 알았습니다. 처음 엔 페이지를 열 때 일부 엔티티가 캐시 된 것처럼 보였습니다.

그런 다음 새 브라우저에서 앱을 열려고했습니다. 이전에 Chrome에서 연 페이지를 열면 즉시 열립니다. 이전에 클릭하지 않은 새 페이지를 열면 ~ 10 초의로드가 발생합니다.

지금 당장 가장 좋은 추측은 내가 사용하는 Entity Framework가 어떤 이유로 문제가되고 있다는 것입니다.

편집 3 :

현상금을 추가하고 많은 로깅을 설정하고 있습니다. MiniProfiler를 추가했지만 프로덕션 환경에서 작업하는 데 문제가 있습니다 (로컬 요청에만 표시됨).

또한 Application_StartApplication_BeginRequest 대한 global.asax 및 일부 및 상태를 보려면 Application_BeginRequest 에 로깅을 추가했습니다. 조만간 결과가 업데이트 될 것입니다.

편집 4 :

이제는 흥미로운 첫 번째 숫자가 있습니다. 앱이 재활용되지 않습니다. Application_Start 는 한 번만 호출됩니다.

EndRequestBeginRequest 에 로그온하여 시차를 확인할 수 있습니다. 두 통화 사이에 +15 초 이상 걸리는 호출이 여러 번 있음을 알 수 있습니다. 그러나 사이트가 따뜻하면 페이지에 따라 0.5-2 초가 걸립니다. 그래서 요청의 시작과 끝 사이에 아주 이상한 일이 일어나고 있습니다. 디버깅 추가!

편집 5 :

MiniProfiler가 작동합니다. 느린로드 (~ 15 초)의 예는 다음과 같습니다.

다음 단계는 Entity Framework 추적을 추가하는 것입니다. 나는 데이터베이스에 돈을 받고있어!

편집 6 :

Okidoki, 나는 틀렸다. 느린 렌더링 방법입니다 - 데이터베이스가 아닙니다! 이 디버깅하는 방법을 모르겠다 ... 구글!

편집 7 :

다른 업데이트를위한 시간. 상태 : 아무 것도 해결되지 않았습니다.

그래서 나는 많은 것을 시도했다.

1) 모든 유형의 캐싱 ( 특성을 사용하는 특정 동작에 대해 ASP.NET MVC에서 캐싱 방지 )을 해제하려고 시도했지만 동일한 동작이있었습니다. 첫 번째로드? 느린. 다음로드? 빠른. 5 분에서 10 분 정도 기다리면 같은 행동이 풀리지 않습니다.

2) 내 startup.auth 파일에 5 분의 지연으로 몇 가지 맞춤 물건이 있습니다. 제거되었습니다. 문제는 아닙니다.

3) 인증을 위해 사용자 정의 속성을 사용했습니다. 나는 그것을 제거했다.

4) 요청에 따라 작동하도록 Entity Framework 구현을 업데이트했습니다.

나는 정말로 좌절하고있다. 다음 단계는 다음과 같습니다.

A) 동일한 페이지를 5-10 버전으로 만들도록 노력하십시오. (레이아웃, 데이터베이스, 데이터베이스없이 의존성 삽입,이 모든 것없이) 패턴을 찾을 수 있는지 확인하십시오.

B) 가상 컴퓨터로 호스팅을 이동하여 문제가 해결되는지 확인합니다.

편집 8 - 새로운 RELIC 추가 :

나는 새로운 유물을 추가했다. 두 가지 매우 무서운 것들은 다음과 같습니다 (나는 오류를 발견하고 재현했습니다!) :

그리고 프론트 엔드 현명하다 (New Relic의 브라우저 부분), 두 가지 시작 사이에 ~ 15 초 부족이있다.

http://prntscr.com/jevgeg vs http://prntscr.com/jevgix 아무것도 들어 있지 않습니다.


몇 가지 아이디어 :

  1. 웹 응용 프로그램 블레이드에서 진단 및 문제 해결 메뉴로 이동하십시오. 그런 다음 성능 카운터를 클릭하십시오. 정직하게도 타임 라인과 성능 저하에주의를 기울여 사용 가능한 성능 카운터를 하나씩 살펴 보겠습니다. 나는 SignalR이 Thread Count를보고 과도한 연결로 인해 서버를 질식시키고 있음을 알게되었습니다.

  2. Application Insights의 서버 오류 로그가 깨끗합니까?

  3. 진단 및 문제 해결 화면에서 실패한 요청 추적 로그에 의심스러운 항목이 있습니까?


나는 가능한 몇 가지 대답을 가지고있다.

엔티티 프레임 워크 코드 우선 / 데이터베이스 초기화 : 마이그레이션 및 가능한 시드 데이터와 함께 코드 첫 번째 설정을 사용하는 경우 이러한 각각의 작업에서 "예열"문제가 발생할 수 있습니다.

특히 앱을 시작할 때 데이터베이스를 초기화하지 않으면 데이터베이스를 처음으로 초기화 할 때 초기화된다는 의미입니다.

Entity framwork 버전 : 엔티티 프레임 워크 자체는 5와 6.x에서 많은 성능 향상을 가져 왔으며 그 중 일부는 콜드 및 웜 시작 속도와 관련이 있습니다.

보기가 미리 컴파일되지 않습니다. 배포 후와 같이 페이지에 느린로드가 발생하는 경우 새 페이지의 첫 번째 조회 (보기)가 발생하면 이후의로드가 정상입니다. 이것은 페이지가 컴파일되지 않았기 때문일 수 있습니다. 그럴 경우 정교 할 수 있습니다.

재활용 응용 프로그램이 재생 될 때 이러한 문제가 발생하는 것처럼 들리며 자동 초기화되지 않습니다 (이것이 바로 콜드 히트를 얻는 이유입니다). 이러한 것들로 보아본 최악의 성능 문제는 대개 엔티티 프레임 워크와 사전 컴파일 관련입니다. 그러나 둘 다 쉽게 고칠 수 있습니다. 그러나 앱을 항상 "실행하고"리사이클 후 자체 초기화하면 사용자가이 콜드 히트를받지 않도록합니다.

업데이트 : 보기 관련이 있기 때문에 나는 매우 유용하다고 생각하는 해결책을 제시 할 수 있습니다. RazorGenerator.Mvc 설치하기 Nuget 패키지. 그리고이 엔진을 첫 번째 엔진으로 추가하면 컴파일 된 뷰를 사용할 수 있습니다.

App_Start 다음과 같은 내용으로 RazorGeneratorMvcStart.cs 라는 파일을 만들 수 있습니다 :

using RazorGenerator.Mvc;

[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(MyNamespace.RazorGeneratorMvcStart), "Start")]

namespace MyNamespace {
    public static class RazorGeneratorMvcStart {
        public static void Start() {
            ViewEngines.Engines.Insert(0, new PrecompiledMvcEngine(typeof(RazorGeneratorMvcStart).Assembly));

            VirtualPathFactoryManager.RegisterVirtualPathFactory(engine);
        }
    }
}

면도기 엔진은 UsePhysicalViewsIfNewer 대한 매개 변수를 취할 수 있습니다. 이 경우 컴파일 된 .dll보다 새로운 날짜의보기가 폴더에 저장되어 있지 않으면 미리 컴파일 된 버전이 사용됩니다.

이 접근법은 뷰의 성능 문제를 해결해야합니다.


번들링 설정에서 Less or Sass를 컴파일하고 있습니까?
그렇다면 어떤 JavaScriptEngineSwitcher를 사용하고 있습니까?
비슷한 문제가 있음을 기억합니다. 번들은 처음 액세스 할 때 컴파일되며 엄청난 시간이 걸립니다.
해결책은 V8 엔진으로 전환하는 것이 었습니다.


찾고 수정할 수있는 옵션이 두 가지 더 있습니다.

1. User New Trace를 유추 하십시오 .

this 게시물을 hanselman에서 Azure 에서 사용하고 있는지 확인하십시오.

2. Asp.Net MVC 모범 사례를 따릅니다.

베스트 프랙티스에 대한 this 게시물을 확인하십시오.

또한 데이터 읽기의 경우 Entity Framework 대신 ADO.NET 을 저장 프로 시저와 함께 사용할 수 있습니다. EF 성능 문제가있을 수 있기 때문입니다.





devops