사용자 컨트롤의 ASP.Net 과도한 사용

Question

각 페이지에서 사용자 컨트롤을 광범위하게 사용하는 asp.net 웹 응용 프로그램을 조사하고 있습니다. 대부분의 페이지에는 약 10-20 개의 사용자 컨트롤이 있습니다. 사용자 정의 컨트롤은 내용이 사용자 정의 컨트롤에있는 탭 컨트롤의 각 탭과 같이 세밀한 세분화가 있지만 비즈니스 개체의 시각적 표현 인 것처럼 보입니다 (이해할 수있는 경우). 프로젝트 자체에는 200 개가 넘는 사용자 컨트롤 (ascx 파일)이 있습니다.

응용 프로그램의 성능이 매우 낮습니다 (그리고 제가 조사하고있는 이유). 각 이벤트 (예 : 클릭 또는 드롭 다운 선택 등)는 페이지를로드하는 데 약 5 초 (Visual Studio에서 10 초)가 필요합니다. 이 애플리케이션은 Ajax를 사용하지 않는다.

aspx 페이지 자체가 코드 숨김에 코드를 가지고 있지 않으므로 추적은 힘들다. 사용자 컨트롤이이 모든 것을 돌봐주기 때문에 단일 페이지를 추적하려면 해당 페이지에있는 모든 사용자 컨트롤에 trace 문이 필요하다.

사실 나는 각 사용자 컨트롤을 비즈니스 코드로 돌리고 재사용 할 수 있다는 것이 현명한 아이디어라고 생각하지만 성능이 저하 될 사용자 컨트롤을 과도하게 사용하고 있다고 생각합니까? 이것은 강력한 WinForms 배경을 가진 사람이 작성한 asp.net 응용 프로그램의 구조처럼 보입니까?

편집
내가 사용자 컨트롤의 사용에 의문을 제기 (또는 금액) 단순히 모든 일을 성취 한 페이지에 너무 많은 필요 여부 (각 사용자 컨트롤이 연결 아니에요 추가해야한다고 생각 예를 들어, 데이터베이스)는 일반적으로 성능 문제를 일으킬 것입니다 ... 예를 들어, 한 사용자가 포스트 백을 수행하여 다른 모든 작업을 처리하는 경우 일부는 표시되고 일부는 그렇지 않습니다 ... @ David McEwing 그는 40 가지의 최적화 된 사용자 컨트롤을 가지고 있었지만, 개발자가 WinForms를 기반으로하거나 "asp.net에 익숙하지 않은"경우, 어떻게 각각 최적화되었는지 확인하려고합니다 ...

EDIT2
SQL 문 추적을 얻은 후 다른 사용자 컨트롤이 일반적으로 저장되지 않은 데이터를 필요로하므로 각 이벤트에 대해 페이지 호출 당 5-6 번 데이터가 실행됩니다. (위에서 언급 한) 탭의 각 사용자 정의 컨트롤은 데이터베이스에서 객체를 채우는 데 동일한 호출을합니다 ... 나는 분명히 문제가되는 사용자 컨트롤 (내가 질문을 삭제해야 하는가?)을 비난하기 위해 여기에 있지 않습니다. 사용자 컨트롤이 아니지만이 특별한 경우에이를 사용하면 과도하다고 믿습니다!

Answer 1

10-20 개 (또는 수백 개)의 사용자 컨트롤만으로도 그다지 중요하지 않습니다. 컨트롤 자체의 존재와 캡슐화의 아이디어는 확실히 당신의 문제의 원천이 아닙니다.

은 무엇 가능성이하는 사업의 특정 구현입니다 :

이 정확하게 문제가 실제로 물론 응용 프로그램을 프로파일 링하지 않고 무엇하지만 내 경험을 바탕으로 내가이 말을 수 있다고하는 것은 불가능하다 각 사용자 컨트롤 내부의 로직이 좋지 않습니다. 설명하는 한 포스트 백이 오래 걸리면 각 컨트롤은 각 요청에 대한 자체 데이터에 대해 DAL을 다시 살펴볼 것입니다. 이것은 두 가지에 의해 완화 될 수있다 :

• 것은 반드시 사용자 컨트롤을 명시 적으로 지시하지 않는 한 (일반적으로 낮은 수준의 서비스에서 이벤트에 의해)을 재로드 결코 그들의 첫 번째로드 데이터 및 를 캐시 확인
• 컨트롤이 모두 데이터를 다시 사용할 수있는 일련의 공통 서비스를 사용하는지 확인하십시오. 예 : 두 개의 컨트롤이 고객 목록에 대한 액세스를 필요로하고 동일한 요청 세션의 컨텍스트에서 실행 중이면 하나의 고객 목록 조회 만 필요합니다.

Answer 2

많은 사용자 컨트롤을 사용하는 응용 프로그램에 익숙하지 않습니까?

응용 프로그램의 익숙하지 않은 부분이 낯선 성능 저하의 원인이라는 결론에 도달 한 것 같습니다. 대신 가정을 만드는, 왜 안 다음 프로파일 링 도구 중 하나를 시도하고 찾아 :

• JetBrains' dotTrace
• Red-Gate ANTS
• Automated QA's AQTime

ASP의이 모든 할 수있는 메모리와 CPU 프로파일 링 .NET 응용 프로그램.

Answer 3

저는 UserControls의 핵심 목적 중 하나가 코드 재사용이라고 생각합니다. 즉, 동일한 기능이 여러 웹 페이지에서 발생하면 UserControl을 만드는 것이 좋습니다.개발자가 동일한 코드를 여러 웹 페이지에 작성 (또는 복사 및 붙여 넣기) 할 수있을뿐만 아니라 유지 관리 작업을 훨씬 쉽게 할 수 있습니다. UserControl에 대한 모든 변경은 UserControl이 사용되는 모든 곳에서 자동으로 구현됩니다. 유지 보수 개발자는 코드가 변경해야하는 모든 다른 장소를 찾는 것에 대해 걱정할 필요가 없습니다.

일회용 UserControl이 효과적인지 잘 모르겠습니다. 바쁜 웹 페이지에서 코드를 캡슐화하고 segreate합니다.

UserControls가 재사용되는지 또는 많은 정보가 한 번만 사용되었는지 확인할 수 있습니까?

Answer 4

나는 어떤 것들이 갖는 영향을 결정하기 위해 프로파일 링을하는 것에 관해 Saunders는 동의합니다. 여기에 IIS에 대한 몇 가지 무료 스트레스 테스트 도구를 얻을 수 있습니다

참고 : http://support.microsoft.com/kb/840671

내가 너무 많은 컨트롤을 가지고하는 것은, 아마 이럴 좋은 일이 아니라고하지만, 말할 것이다. 더 많이 알지 못하면 잠깐 20이 너무 많다고 말합니다.

Answer 5

페이지에서 사용되어야하는 사용자 컨트롤의 수에 제한이 없다는 것을 분명히 알 수 있습니다. 페이지 수준 추적 대신 여기에 응용 프로그램 전체 추적이있는 것처럼 들립니다. 소수의 컨트롤이 문제의 원인이 될 수 있습니다. 지옥, 그것은 모든 소란을 일으키는 단 하나 통제 일 수 있었다. 그러나 "평균적인"(있을 경우) 사용자 제어가 사용되는 리소스 사용 수준에 대해 어떤 가정도하지 못하기 때문에 제한을 제안하는 것도 불가능합니다. 그렇지 않으면 클래스에 대한 멤버 수나 데이터베이스에 대한 저장 프로 시저의 수와 비슷한 한계가 생길 수 있습니다.

새로 고침 할 때마다 각각 자신의 데이터를 검색하는 20 개의 복잡한 사용자 정의 컨트롤이 필요하거나 필요하지 않더라도 ViewState를 사용하여 하위 컨트롤 집합을 구성하는 경우 문제가 발생합니다. 그러나 너무 많은 컨트롤이있는 것보다 전반적인 디자인과 관련이 있습니다.반면에 텍스트 상자의 왼쪽에있는 레이블 (또는 레이블 + 사용자가 실행 가능한 컨트롤의 모든 조합까지)의 합성물 이상으로 작동 할 수있는 공통 사용자 정의 컨트롤을 만들고이를 뿌렸다면 앱 전체에서 제어 할 수 있다면 페이지에서 이러한 항목을 얻을 수 있다고 생각할 수 있습니다. 그러면 왜 그 항목이 반드시 손상 될지 알 수 없습니다.