ASP.NET MVC가 ASP.NET WebForms보다 30 배 빠르다는 야생 발언을 발견했습니다. 실제 성능 차이가 무엇인지, 이것이 측정되었으며 성능 이점은 무엇입니까?

이것은 ASP.NET WebForms에서 ASP.NET MVC로 이동하는 것을 고려하는 데 도움이됩니다.

결론을 내리는 데 필요한 유형의 확장 성 및 성능 테스트를 수행하지 않았습니다. ScottGu가 잠재적 인 성능 목표에 대해 논의하고 있었던 것 같습니다. 베타 및 RTM으로 이동함에 따라 내부적으로 더 많은 성능 테스트를 수행 할 것입니다. 그러나 성능 테스트 결과 게시에 대한 Google 정책이 무엇인지 잘 모르겠습니다.

어쨌든 이러한 테스트는 실제 응용 프로그램을 고려해야합니다.

A) WebForms 응용 프로그램을 구현하는 방법 및 B)에 따라 달라지기 때문에 이것은 확실히 대답하기 어려운 질문이 될 것이라고 생각합니다. 을 구현하는 방법 MVC 응용 프로그램을 구현하는 방법 합니다. "원시"형태에서 MVC는 WebForms보다 빠를 가능성이 있지만 수년 및 수년간의 도구와 경험을 통해 빠른 WebForms 응용 프로그램을 구축하기위한 여러 기술을 만들어 냈습니다. 저는 선임 ASP.NET 개발자가 MVC 응용 프로그램의 속도에 필적하는 WebForms 응용 프로그램을 만들거나 최소한 무시할만한 차이를 얻을 수 있다고 확신합니다.

@tvanfosson이 제안한 실제 차이점 은 테스트 가능성과 깨끗한 SoC입니다. 성능 향상이 가장 큰 관심사라면 WebForms로 이동하여 MVC에서 재 구축을 시작하는 것이 큰 이유가 아니라고 생각합니다. 적어도 WebForms를 최적화하기 위해 사용 가능한 기술을 시도 할 때까지는 아닙니다.

viewstate를 제거하고 제출 된 출력으로 작업 할 수 있도록 프로그래밍 방식으로 견딜 수있게함으로써 내 페이지 중 하나를 2MB 페이로드에서 200k로 줄였습니다.

처리량이 동일하더라도 크기만으로도 초당 연결과 요청 속도가 크게 향상됩니다.

WebForms가 본질적으로 느리거나 리소스 집약적이라고 생각하는 많은 사람들이 잘못된 위치에 책임을지고 있다고 생각합니다. 웹 양식 앱을 최적화하기 위해 10 점 만점에 9 번은 앱 작성자가 뷰 스테이트의 목적을 오해하는 곳이 너무 많습니다. 나는 viewstate가 완벽하다고 말하는 것이 아니라 그것을 남용하기가 너무 쉽습니다. 그리고 이것이 비대해진 viewstate 필드를 일으키는 원인이되는 것은 바로이 남용입니다.

이 기사는 이러한 많은 학대를 이해하는 데 도움이되지 않았습니다. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

MVC와 WebForms를 올바르게 비교하려면 두 앱이 모두 아키텍처를 올바르게 사용하고 있는지 확인해야합니다.

내 테스트는 MVC에서 초당 2 배에서 7 배 더 많은 요청을 보여 주지만 웹 양식 앱을 빌드하는 방법에 따라 다릅니다. 서버 측 제어없이 "hello world"텍스트 만 있으면 mvc가 약 30-50 % 더 빠릅니다.

나에게 MVC의 진정한 "성능"향상은 응용 프로그램의 테스트 가능한 표면을 증가시키는 것입니다. WebForms에는 테스트하기 어려운 많은 응용 프로그램이있었습니다. MVC를 사용하면 테스트 할 수있는 코드의 양이 기본적으로 두 배가됩니다. 기본적으로 쉽게 테스트 할 수없는 것은 레이아웃을 생성하는 코드뿐입니다. 뷰에 사용 된 실제 데이터를 채우는 로직을 포함하여 모든 비즈니스 로직 및 데이터 액세스 로직을 이제 테스트 할 수 있습니다. 더 성능이 좋을 것으로 기대하지만 페이지 수명주기가 크게 단순화되고 웹 프로그래밍에 더 잘 적용됩니다.

여기서 문제는 ASP.Net MVC가 이전 웹 양식보다 얼마나 빠르더라도 차이를 만들지 않을 것입니다. 대부분의 시간이 데이터베이스에 있기 때문입니다. 대부분의 경우 웹 서버는 데이터베이스 서버에서 대기하는 것만으로도 CPU 사용량이 0 ~ 10 %입니다. 웹 사이트에서 매우 많은 수의 히트가 발생하고 데이터베이스가 매우 빠르지 않으면 큰 차이를 느끼지 못할 것입니다.

초기 ASP.NET MVC 개발에서 찾을 수있는 유일한 구체적인 숫자는이 포럼 스레드에 있습니다.

http://forums.asp.net/p/1231621/2224136.aspx

Rob Connery는 ScottGu가 ASP.NET MVC가 초당 8000 개의 요청을 처리 할 수 ​​있다고 주장했다는 진술을 어느 정도 확인했습니다.

아마도 Jeff와 그의 팀은이 사이트의 개발에 대한 힌트를 줄 수 있습니다.

받아 들여진 의견과는 달리 최적화 된 웹 양식 사용은 원시 성능 측면에서 MVC를 완전히 죽입니다. Webforms는 MVC보다 훨씬 오래 html을 제공하는 작업에 최적화되었습니다.

메트릭은 http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db에서 사용할 수 있습니다 .

모든 단일 비교 mvc는 목록의 중하 위 / 하위 순위에있는 반면 최적화 된 웹 양식 사용은 상위-중간 / 상하위 순위에 있습니다.

일화 적이지만 이러한 메트릭에 대한 매우 심각한 검증 인 www.microsoft.com 은 MVC가 아닌 웹 양식에서 제공됩니다. 경험적으로 더 빠르다면 MVC를 선택하지 않았을 것이라고 여기는 사람이 있습니까?

대답 할 방법이 정말 없습니다. MVC는 기본적으로 Web Forms보기 엔진을 자체적으로 사용하며 사용자 지정보기 엔진을 원하는만큼 사용하도록 구성 할 수 있으므로 성능 비교를 원하는 경우 더 구체적이어야합니다.

나는 약 1 년 전에 MVC에서 일을 시작했는데 영감을 받았지만 감명받지 못했습니다.

나는 뷰 상태를 싫어하고 ASP.NET 측면에서 모든 악의 근원이라고 생각합니다. 이것이 내가 그것을 사용하지 않는 이유이며 완벽하게 솔직히 당신은 왜 그렇게 하시겠습니까?

기본적으로 ASP.NET MVC Framework 개념을 가져 와서 제 방식으로 구축했습니다. 그래도 몇 가지를 변경했습니다. 컨트롤러 래핑 코드 또는 동적 재 컴파일에 대한 URL 라우팅 코드를 구축했습니다.

이제 ASP.NET MVC 응용 프로그램은 사용 방법에 따라 더 빨라질 것이라고 말할 수 있습니다. WebForms를 완전히 포기하면 ASP.NET 수명주기와 개체 모델이 엄청 나기 때문에 더 빨라질 것입니다.

글을 쓸 때 군대를 인스턴스화하는 것입니다 ... 기다리지 마세요. 뷰 렌더링에 참여할 개체 군단입니다. 이것은 ASPX 페이지 자체에서 최소한의 동작을 표현할 때보 다 느려질 것입니다. (Visual Studio의 ASPX 페이지에 대한 지원이 괜찮 기 때문에 뷰 엔진 추상화에 대해서는 신경 쓰지 않지만, WebForms를 개념으로 완전히 삭제했으며 코드가 부풀거나 내 응용 프로그램을 연결하는 것).

필요할 때마다 특수 목적의 개체와 코드를 생성하기 위해 동적 재 컴파일 (System.Reflection.Emit)에 의존하는 방법을 찾았습니다. 이 코드의 실행은 리플렉션보다 빠르지 만 처음에는 리플렉션 서비스를 통해 빌드됩니다. 이것은 내 MVC 풍미의 프레임 워크에 뛰어난 성능을 제공했지만 매우 정적으로 형식화되었습니다. 문자열과 이름 / 값 쌍 컬렉션을 사용하지 않습니다. 대신 내 사용자 정의 컴파일러 서비스는 참조 유형이 전달되는 컨트롤러 작업에 양식 게시물을 다시 작성합니다. 이면에는 많은 일이 진행되고 있지만이 코드는 WebForms 또는 MVC 프레임 워크보다 훨씬 빠릅니다.

또한 URL을 작성하지 않고 나중에 호출 할 컨트롤러 작업을 알려주는 URL로 변환되는 람다 식을 작성합니다. 이것은 특별히 빠르지는 않지만 깨진 URL을 능가합니다. 정적으로 형식화 된 리소스와 정적으로 형식화 된 개체가있는 것과 같습니다. 정적으로 형식화 된 웹 애플리케이션? 그것이 내가 원하는 것입니다!

나는 더 많은 사람들이 이것을 시도하도록 권장합니다.

Visual Studio로 만든 프로젝트. 하나는 mvc4 템플릿이고 다른 하나는 WebForm (전통적)입니다. 그리고 WCAT로 부하 테스트를 할 때 이것이 결과입니다.

MVC4는 WebForms보다 상당히 느립니다. 아이디어가 있습니까?

MVC4

• 약 11rps를 얻을 수 있습니다
• rps는 2-cpu 또는 4-cpu 서버 모두 매우 낮습니다.

WebForms (aspx)

• 2500rps 이상을 얻을 수 있습니다.

• 성능 킬러는 MVC Bata 또는 RC의 버그라는 사실이 밝혀졌습니다. 그리고 번들을 제거하면 성능이 향상됩니다. 이제 최신 버전이이 문제를 해결했습니다.

성능은 수행중인 작업에 따라 다릅니다. 일반적으로 MVC는 주로 Viewstate가없고 MVC가 기본적으로 Postback보다 콜백에서 더 많이 작동하기 때문에 asp.net보다 빠릅니다.

웹 양식 페이지를 최적화하면 MVC와 동일한 성능을 가질 수 있지만 많은 작업이 필요합니다.

또한 CSS와 자바 스크립트를 결합 및 축소하고 이미지를 그룹화하고 스프라이트로 사용하는 등 웹 사이트 성능을 개선하는 데 도움이되는 MVC (및 Webform 용)에 대한 많은 너겟입니다.

웹 사이트의 성능은 아키텍처에 따라 크게 달라집니다. 관심사를 잘 분리 한 깨끗한 코드는 더 깨끗한 코드와 성능 향상 방법에 대한 더 나은 아이디어를 제공합니다.

이 템플릿 " Neos-SDI MVC 템플릿 "을 살펴보면 기본적으로 많은 성능 향상이있는 깨끗한 아키텍처를 만들 수 있습니다 ( MvcTemplate 웹 사이트 확인 ).

몇 가지 기본 코드로 소규모 VSTS 부하 테스트 실험을 수행 한 결과 ASP.NET MVC 응답 시간이 ASP.NET Webforms에 비해 두 배 더 빠르다는 것을 알았습니다. 위는 플롯과 함께 첨부 된 그래프입니다.

이 부하 테스트 실험은이 CP 기사 https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari 에서 자세히 읽을 수 있습니다.

테스트는 VSTS 및 telerik 부하 테스트 소프트웨어를 사용하여 아래 사양으로 수행되었습니다.

사용자는 25 명의 사용자를로드합니다.

테스트 실행 시간은 10 분이었습니다.

시스템 구성 DELL 8GB Ram, Core i3

프로젝트는 IIS 8에서 호스팅되었습니다.

프로젝트는 MVC 5를 사용하여 생성되었습니다.

네트워크 LAN 연결이 가정되었습니다. 따라서이 테스트는 현재 네트워크 지연을 고려하지 않습니다.

테스트에서 선택한 Chrome 및 Internet Explorer의 브라우저입니다.

알 수없는 이벤트의 평균을 내기 위해 테스트 중에 여러 번 읽었습니다. 7 개의 읽기와 모든 읽기는이 기사에서 읽기 1, 2 등으로 게시됩니다.