우리는 사용자 정의 컨트롤을 동적으로로드하는 다소 복잡한 페이지가 있습니다 (일부는 중첩되어 있음). 매우 느린 실행 페이지입니다.ASP.NET 페이지 성능
컨트롤을 동적으로 추가하면 병목 현상이 추가 될 수 있습니까? .NET 캐시 개체에 컨트롤을 추가하고 이미 캐시에 LoadControl을 사용하지 않으면 도움이 될까요?
페이지를 빠르게 만드는 데 필요한 다른 팁이나 전략은 무엇입니까?
@Page 지시어에 Trace = "true"를 추가하면 어떤 방법이 가장 길게 걸리는지 확인할 수 있습니다.
동적으로 컨트롤을로드하는 동작이 느려지는 것을 의심하고 각 컨트롤의 동작을 더 많이 의심합니다. 그들은 모두 DB에 충돌합니까? 로드를 최적화하기 전에 컨트롤의 성능을 간소화 할 수 있는지 (DB 호출 캐싱 등) 확인할 것입니다.
한 번 우리는 ASP.Net 프로젝트 성능을 한 단계 향상 시켰습니다. 우리가 시도한 것들의 목록은 다음과 같습니다.
진정한 속도 저하가 어디에서 발생하는지 보려면 페이지에서 프로파일 링을 수행하십시오. 보통 내 경험에 비추어 볼 때 실제 속도가 느려질 수 있다고 생각하는 것은 가장 느린 곳이 아닙니다. 느린 실행을 시작할 때 내 앱/페이지를 프로파일 링하는 것이 가장 좋은 것으로 밝혀졌으며, 그 다음에 어떤 부분에서 아주 좋은 정보를 얻을 수있어 극적인 재주를 빨리 얻을 수있었습니다. 당신은 너무 많은 DB 호출, 또는 usercontrol 로딩, 또는 당신이 고려하지 않은 것을 찾을 수 있습니다.
단순히 컨트롤을 동적으로로드하면 큰 성능 비용이 발생하는 것에 놀랐습니다.그러나 많은 컨트롤이 있고 깊이 중첩되어있는 경우 ASP.NET은 때때로 HTML로 렌더링하는 속도가 매우 느릴 수 있습니다. 분명히 다른 사람들이 당신의 병목이 실제로 어디에 있는지를 결정할 것을 제안하면서 프로파일 링을 수행하십시오.
확인해야 할 것은 복잡한 페이지의 경우 렌더링 된 html의 크기입니다. 많은 서버 컨트롤을 사용하면 페이지 크기가 놀랍게도 빠르게 여러 메가 바이트까지 올라갈 수 있습니다. HTTP 압축을 켜거나 조정하면 원하는 답을 얻을 수 있습니다.
성능 문제를 조사하는 첫 번째 단계는 병목 현상을 확인하는 것입니다. 네트워크 트래픽 (너무 많은 HTTP 요청, 너무 많은 HTML이 파이프를 통과합니까?) 또는 서버의 CPU 바운드입니까? 또는 너무 많은 데이터베이스 호출?
많은 경우 속도가 느려지는 페이지의 크기입니다. 페이지에 많은 컨트롤을 포함한다면 많은 HTML이있을 것이므로 최종 렌더링 된 제품에서 뷰 소스를 작성하고 20000 줄의 HTML/javascript를 찾으면 둔화가 너무 심할 것입니다 데이터가 네트워크를 통해 전송됩니다.
YSlow와 같은 도구를 사용하면 최종 렌더링 된 제품을 더 잘 이해할 수 있습니다. 에
주요 항목을 보려면 다음
로딩 사용자 컨트롤을 요청 동적으로 느린 성능의 원인이되는 것은 아닙니다. 일반적으로 ASPX 페이지 성능을 획기적으로 저하시키는 것은 viewstate입니다. 비록 당신이 일부 컨트롤에서 그것을 가능하게했다하더라도] 페이지에서 viewstate를 가져 오는 것이 좋습니다.
서버에 세션 변수로 전체 viewstate를 저장하고 viewstate 필드에 식별자 만 전송하십시오. 당신은 완전한 기사 here을 볼 수 있으며, 기사는 또한 성과 측정 지표를 제공합니다.
웹 페이지가 느린 수행자가 될 수있는 많은 이유가 있습니다. 성능 마법사와 같은 도구를 사용하여 진행 상황을 확인해야합니다.
최신 성능 문제는 익명 형식 및 linq로 요약되었습니다. 모든 JIT 컴파일 작업이 진행되므로이 두 가지 작업으로 성능을 죽이는 것은 매우 쉽습니다.
추측하지 마십시오. 법안. –