Wydajność ASP.NET MVC

102

Znalazłem dziwne uwagi, że ASP.NET MVC jest 30x szybszy niż ASP.NET WebForms. Jaka jest rzeczywista różnica w wydajności, czy została zmierzona i jakie są korzyści związane z wydajnością.

Ma to pomóc mi rozważyć przejście z ASP.NET WebForms do ASP.NET MVC.

GEOCHET
źródło
20
Po pracy z WebForms od momentu ich pojawienia się, nigdy nie wrócę z ochotą! MVC ukradł moje <3 - a ta strona działa niesamowicie na Beta 5!
Jarrod Dixon
2
O co chodzi ze wszystkimi cofnięciami wersji w tym pytaniu…?
Nick
@Nick: OP wycofuje wszelkie zmiany i usuwa komentarze, które je wyjaśniają.
GEOCHET
@Rich B: Dobrze, usunął około 5 moich komentarzy.
George Stocker
2
Potrzebuje aktualizacji teraz, gdy zbliżamy się do wydania MVC3.
Andrew Lewis

Odpowiedzi:

69

Nie przeprowadziliśmy testów skalowalności i perfekcji niezbędnych do wyciągnięcia jakichkolwiek wniosków. Myślę, że ScottGu mógł dyskutować o potencjalnych celach perf. W miarę zbliżania się do wersji Beta i RTM będziemy wewnętrznie przeprowadzać więcej testów wydajności. Nie jestem jednak pewien, jakie są nasze zasady dotyczące publikowania wyników testów perf.

W każdym razie takie testy naprawdę muszą uwzględniać rzeczywiste zastosowania ...

Haacked
źródło
13
Po wydaniu MVC, czy jest jakaś aktualizacja dotycząca publikowania wyników perf?
chris
6
Głosuję tylko na to, ponieważ wynik 5 999 rep. Przedtem rani mnie w oczy :(
Damien
2
Do tego czasu z pewnością musisz mieć już jakieś liczby. Chcesz zaktualizować swoją odpowiedź? A może zauważyłeś, że nieznośna polityka zabrania tego?
tvanfosson
7
Liczba to 42. :) Ogólnie rzecz biorąc, nasze liczby będą prawdopodobnie bezużyteczne dla rzeczywistych aplikacji, więc z reguły ich nie udostępniamy. Znam jednak inne zespoły w firmie Microsoft budujące witryny internetowe na dużą skalę, które pokazują korzystne liczby. Innymi słowy, wszelkie problemy z perfekcją są bardziej prawdopodobne z powodu błędów programisty niż problemów dziedziczonych w frameworku. Zazwyczaj przyczyną są interakcje z bazą danych i usługami zewnętrznymi. :)
Haacked
Prawdziwe! Zaktualizuj to! Może nie benchmarki, ale krótki pomysł, czy są na równi, czy też mvc jest trochę lepszy pod względem perf?
gideon
48

Myślę, że ostateczna odpowiedź na to pytanie będzie trudna, ponieważ wiele będzie zależeć od A) sposobu implementacji aplikacji WebForms oraz B) sposobu implementacji aplikacji MVC. W swoich „surowych” formach MVC jest prawdopodobnie szybsze niż formularze internetowe, ale lata i lata narzędzi oraz doświadczenia zaowocowały szeregiem technik tworzenia szybkich aplikacji formularzy WebForm. Byłbym skłonny założyć się, że starszy programista ASP.NET mógłby stworzyć aplikację WebForms, która rywalizuje z szybkością dowolnej aplikacji MVC - lub przynajmniej osiągnąć pomijalną różnicę.

Prawdziwa różnica - jak zasugerował @tvanfosson - polega na testowalności i czystym SoC. Jeśli poprawa wydajności jest Twoim głównym zmartwieniem, nie sądzę, że jest to dobry powód, aby przeskoczyć z WebForms i rozpocząć przebudowę w MVC. Przynajmniej dopóki nie wypróbujesz dostępnych technik optymalizacji formularzy internetowych.

Todd
źródło
Świetna odpowiedź, Todd (jakie zaskakujące dla ewangelisty-programisty jest rzeczywiście pragmatyczna odpowiedź). Jedyne, co się pomyliło, to fakt, że formularz internetowy dotyczący surowych wdrożeń jest rzeczywiście znacznie szybszy.
Chris Marisic
42

Zmniejszyło to jedną z moich stron z 2 MB do 200 KB, po prostu eliminując stan widoku i umożliwiając programową pracę z przesłanymi danymi wyjściowymi.

Sam rozmiar, mimo że przetwarzanie było takie samo, spowoduje znaczną poprawę połączeń na sekundę i szybkości żądań.

DevelopingChris
źródło
31
mogłeś naprawić ten nieznośny duży stan wyświetlania również bez MVC
Andrei Rînea,
1
Aby uzyskać szczegółowe informacje, ViewState można wyłączyć na poziomie strony lub w pliku web.config
bbqchickenrobot
8
tak, ale w mvc jest to rozsądne domyślne rozwiązanie, a nie decyzja projektowa, która zmusza cię do opuszczenia wszystkich kontrolek i dostawców, którzy twierdzą, że pracują tylko na formularzach internetowych, powodując, że formularze internetowe „źle zachowują się”, usuwając ich kręgosłup. Nie zaprzeczam, że mogłeś po prostu przekodować tę stronę, ale cała aplikacja była lepsza bez stanu wyświetlania.
DevelopingChris
czy nie sądzisz, że to najgorsza decyzja, jaką podjąłeś, aby przenieść całą aplikację do MVC, zamiast wyłączać stan widoku w web.config? i nie, stan widoku nie jest kręgosłupem. tylko jeśli zbadałeś, stan widoku może być przechowywany w pamięci podręcznej, jak również w sesjach.
Simple Fellow
29

Myślę, że wiele osób, które uważają, że formularze internetowe są z natury powolne lub wymagają dużej ilości zasobów, obarcza winę niewłaściwym miejscem. 9 razy na 10, kiedy jestem zmuszany do optymalizacji aplikacji webforms, jest zbyt wiele miejsc, w których autorzy aplikacji nie rozumieją celu stanu wyświetlania. Nie mówię, że stan widzenia jest doskonały, czy coś w tym stylu, ale zbyt łatwo jest go nadużywać i to jest to nadużycie, które powoduje rozdęte pole widzenia.

Ten artykuł był nieoceniony, ponieważ pomógł mi zrozumieć wiele z tych nadużyć. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Aby dokonać prawidłowego porównania między MVC i WebForms, musimy mieć pewność, że obie aplikacje poprawnie używają architektur.

Ariel
źródło
14

Moje testy pokazują od 2x do 7x więcej wymagań na sekundę w MVC, ale to zależy od tego, jak zbudujesz aplikację webforms. Mając tylko tekst „hello world”, bez żadnej kontroli po stronie serwera, mvc jest około 30-50% szybsze.

Hrvoje Hudo
źródło
12

Dla mnie prawdziwą poprawą "wydajności" w MVC jest zwiększenie testowalnej powierzchni aplikacji. W przypadku WebForms było wiele aplikacji, które były trudne do przetestowania. Dzięki MVC ilość kodu, który można przetestować, zasadniczo się podwaja. Zasadniczo wszystko, co nie jest łatwe do przetestowania, to kod generujący układ. Cała logika biznesowa i logika dostępu do danych - w tym logika, która wypełnia rzeczywiste dane używane w widoku - jest teraz dostępna do testowania. Chociaż spodziewam się, że będzie on również bardziej wydajny - cykl życia strony jest znacznie uproszczony i bardziej dostosowany do programowania internetowego - nawet gdyby był taki sam lub nieco wolniejszy, warto byłoby przejść na niego z perspektywy jakości.

tvanfosson
źródło
Naprawdę chciałbym wiedzieć, dlaczego ktoś zlekceważył tę odpowiedź.
tvanfosson
Mam wrażenie, że może zostać odrzucony, ponieważ dobrze zaprojektowana aplikacja formularzy internetowych ASP.NET jest tak samo testowalna jak aplikacja MVC. Moje doświadczenie z rozwijaniem obu jest takie, że MVC zmusza cię do stworzenia czystego modelu programowania (co jest jedną z jego największych zalet, IMO). Formularze internetowe pozwalają robić rzeczy leniwie, ale nadal jest bardzo możliwe, aby mieć taką samą testowalną powierzchnię w formularzach internetowych. W każdym razie to moje przypuszczenie.
dudemonkey
Widoki Razor dosłownie zachęcają do osadzania kodu w widoku. Tego nie da się przetestować i nie wróży dobrze oddzielenia problemów. To, że MVC sprawia, że ​​piszesz kontrolery, nie oznacza, że ​​nie możesz tego wszystkiego zepsuć, jeśli nie wiesz, co robisz. Wykwalifikowany programista uzyska taką samą wydajność z formularzy internetowych (lub więcej) niż MVC i będzie miał praktycznie identyczną „testowalną powierzchnię”.
Richard Hauer
@RichardHauer to było dosłownie nieprawda, kiedy to pisałem, ale poprawili to. Ponieważ WebForms nie wydaje się mieć przyszłości w .NET Core, wydaje się, że jest to kwestia sporna.
tvanfosson
@tvanfosson Zgoda - teraz jest dyskusyjna. Nie jesteś pewien, który fragment Twoim zdaniem jest nieprawdziwy, być może sprzeciwiasz się używaniu przeze mnie słowa „dosłownie”? W każdym razie nowsze wersje MVC z TagHelpers pomagają przełamać zwyczaj umieszczania kodu w układach, które mogą w końcu sprawić, że wszystko będzie dla mnie działać. Doceń, że ten post jest oczywiście dość stary, ale nawet w tamtym czasie dobrze skonstruowany formularz WebForms jest bardzo szybki, bez "magicznego okablowania" MVC i żadnego kodu osadzonego w widoku.
Richard Hauer
7

Myślę, że problem polega na tym, że bez względu na to, o ile szybszy jest ASP.Net MVC niż stare formularze internetowe, nie ma to znaczenia, ponieważ większość czasu zajmuje baza danych. W większości przypadków serwery internetowe będą siedzieć z obciążeniem 0-10% procesora tylko czekając na serwerze bazy danych. Jeśli nie masz bardzo dużej liczby odwiedzin w swojej witrynie, a Twoja baza danych jest niezwykle szybka, prawdopodobnie nie zauważysz dużej różnicy.

Kibbee
źródło
Twoi użytkownicy mogą - brak stanu widoku.
UpTheCreek
6

Jedyne konkretne liczby, które mogę znaleźć, które pochodzą z wczesnego rozwoju ASP.NET MVC, znajdują się w tym wątku na forum:

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

Sam Rob Connery nieco potwierdza stwierdzenie, że ScottGu twierdził, że ASP.NET MVC może obsługiwać 8000 żądań na sekundę.

Może Jeff i jego ekipa mogą dać jakąś wskazówkę dotyczącą ich rozwoju tej strony.

Seb Nilsson
źródło
3

Wbrew przyjętej opinii, zoptymalizowane użycie formularzy internetowych całkowicie zabija MVC pod względem surowej wydajności. Formularze internetowe zostały zoptymalizowane pod kątem obsługi html znacznie dłużej niż MVC.

Dane są dostępne pod adresem http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Każde porównanie mvc znajduje się w dolnych środkowych / dolnych i górnych rankingach listy, podczas gdy zoptymalizowane wykorzystanie formularzy internetowych plasuje się na wyższych środkowych / wyższych niższych rankingach.

Anegdota, ale bardzo poważna weryfikacja tych wskaźników, witryna www.microsoft.com jest obsługiwana przez formularze internetowe, a nie MVC. Czy ktoś tutaj uważa, że ​​nie wybrałby MVC, gdyby było empirycznie szybsze?

Chris Marisic
źródło
2

Naprawdę nie ma sposobu, aby odpowiedzieć na to pytanie. MVC domyślnie korzysta z mechanizmu widoku formularzy sieci Web i można go skonfigurować do używania dowolnej liczby niestandardowych silników widoku, więc jeśli chcesz porównać wydajność, musisz być bardziej szczegółowy.

Gerald
źródło
2

Zacząłem pracę w MVC około rok temu, byłem zainspirowany, ale nie zrobiło to na mnie wrażenia.

Brzydzę się stanem widoku i uważam go za źródło wszelkiego zła związanego z ASP.NET. Dlatego po prostu go nie używam i, szczerze mówiąc, dlaczego miałbyś to robić?

Zasadniczo wziąłem koncepcję ASP.NET MVC Framework i zbudowałem to na swój własny sposób. Zmieniłem jednak kilka rzeczy. Zbudowałem mój kod opakowujący kontroler lub kod routingu URL wokół dynamicznej rekompilacji.

Teraz chciałbym powiedzieć, że aplikacje ASP.NET MVC będą szybsze w zależności od tego, jak ich używasz. Jeśli całkowicie zrezygnujesz z WebForms, będziesz szybszy, ponieważ cykl życia ASP.NET i model obiektowy są ogromne.

Kiedy piszesz, tworzysz instancję armii ... nie czekaj, legion obiektów, które będą uczestniczyć w renderowaniu twojego widoku. Będzie to wolniejsze, niż gdybyś wyraził minimalną ilość zachowania na samej stronie ASPX. (Nie obchodzi mnie abstrakcja silnika widoku, ponieważ obsługa stron ASPX w Visual Studio jest przyzwoita, ale całkowicie porzuciłem WebForms jako koncepcję i zasadniczo każdą strukturę ASP.NET z powodu rozdęcia kodu lub braku możliwości zmiany rzeczy, które łączą moją aplikację).

Znalazłem sposoby polegające na dynamicznej rekompilacji (System.Reflection.Emit) do emitowania obiektów i kodu specjalnego przeznaczenia w razie potrzeby. Wykonywanie tego kodu jest szybsze niż odbicie, ale początkowo jest kompilowane za pośrednictwem usługi odbicia. Dało to mojej strukturze o smaku MVC doskonałą wydajność, ale także bardzo statycznie typizowaną. Nie używam ciągów i kolekcji par nazwa / wartość. Zamiast tego moje niestandardowe usługi kompilatora przechodzą i przepisują post formularza do akcji kontrolera, do której jest przekazywany typ referencyjny. Za kulisami dzieje się wiele rzeczy, ale ten kod jest szybki, dużo szybszy niż WebForms lub MVC Framework.

Ponadto nie piszę adresów URL, piszę wyrażenia lambda, które są tłumaczone na adresy URL, które później informują, którą akcję kontrolera należy wywołać. Nie jest to szczególnie szybkie, ale pokonuje uszkodzone adresy URL. To tak, jakbyś miał zarówno statycznie wpisane zasoby, jak i statycznie wpisane obiekty. Aplikacja internetowa z typem statycznym? To jest to czego chcę!

Zachęcałbym więcej osób do wypróbowania tego.

John Leidegren
źródło
2
Więc to nie jest bezpośrednia odpowiedź na pytanie? Jest to jednak powiązane i ma kilka dobrych punktów. Ale hej, to coś, co zbudowałem na własne potrzeby i doskonale mi pasuje. Lubię też dzielić się moimi pomysłami, nawet jeśli bardzo niewiele osób rozumie dlaczego.
John Leidegren
1
Cóż, nie musisz zmieniać swojego głosu, ale nie musisz oddawać głosu negatywnego, ponieważ nie jest to „odpowiedź”. Jeśli przyjrzysz się tekstowi, jest kilka rzeczy, które wskazują na to, że ASP.NET MVC jest szybszy niż formularze WebForms i dlaczego tak jest. Sprowadza się to do takich rzeczy, jak odbicie i model obiektowy oraz narzut ViewState na WebForms.
John Leidegren
@John - teraz, gdy MVC2 nie ma ulepszonego wiązania modelu, walidacji, silnie wpisanych pomocników itp., Jak oceniasz to w porównaniu do swojej metody?
tvanfosson
MVC2 jest o wiele lepszy, wydaje mi się, że prawie zastąpił to, co wtedy budowałem (z MVC1 w wersji beta). Natknąłem się na dość ciężką próbę problemów związanych z tym, co próbowałem zbudować na bazie ASP.NET, bez rezygnacji z istniejących narzędzi. Wystarczy powiedzieć, że wiele się nauczyłem i ostatecznie wprowadziłem to do produkcji. Teraz zdaję sobie sprawę, że obecne narzędzia / framework (VS / ASP.NET / C #) nie są do tego przystosowane i ostatecznie, jeśli chcesz iść tą drogą, będziesz musiał zainwestować we własne kompilatory / sprawdzanie modeli rzeczy, aby niektóre rzeczy działały na Twoją korzyść.
John Leidegren,
W tamtym czasie niewiele myślałem o ASP.NET MVC. Brakowało rzeczy, o których wiedziałem, że chcę. Ale musiałem spędzić dużo czasu na opracowywaniu, testowaniu i wymyślaniu tych rzeczy. Nadal uważam, że statyczny aspekt struktury sieciowej, którą budowałem, jest pod tym względem lepszy od MVC, ale kompilator C # jest nieefektywny do rozwiązania tego problemu. Potrzebujesz języka / kompilatora, który zapewni większą elastyczność, jeśli chodzi o programowanie meta. Musiałem dużo tego robić w czasie wykonywania i często nie można było buforować skompilowanych instancji, więc musiałem dużo dynamicznie rekompilować.
John Leidegren
2

Projekty stworzone w Visual Studio. Jeden to szablon mvc4, drugi to WebForm (tranditional). A kiedy wykonasz test obciążenia za pomocą WCAT, to jest wynik,

MVC4 jest dość powolny niż formularze internetowe, jakieś pomysły?

wprowadź opis obrazu tutaj

MVC4

  • mógł uzyskać około 11 rps
  • rps jest dość niski zarówno dla serwerów 2-cpu, jak i 4-cpu

wprowadź opis obrazu tutaj

WebForms (aspx)

  • może przekroczyć 2500 rps

  • okazało się, że zabójca wydajności to błąd MVC Bata lub RC. Wydajność uległaby poprawie, gdy usunę rzeczy z pakietów. Teraz najnowsza wersja to naprawiła.

jihe.wei
źródło
1

Wydajność zależy od tego, co robisz ... Zwykle MVC jest szybszy niż asp.net, głównie dlatego, że nie ma Viewstate i ponieważ MVC domyślnie działa bardziej z funkcją wywołania zwrotnego niż ogłaszania zwrotnego.

Jeśli zoptymalizujesz stronę formularza internetowego, możesz uzyskać taką samą wydajność jak MVC, ale będzie to dużo pracy.

Ponadto jest tam wiele nugetów dla MVC (a także dla formularzy internetowych), które pomogą Ci poprawić wydajność witryny, takie jak łączenie i zmniejszanie CSS i JavaScript, grupowanie obrazów i używanie ich jako sprite, i tak dalej.

Wydajność witryny zależy w dużej mierze od Twojej architektury. Czysty kod z dobrym oddzieleniem problemów zapewni bardziej czysty kod i lepsze wyobrażenie o tym, jak poprawić wydajność.

Możesz rzucić okiem na ten szablon „ Neos-SDI MVC Template ”, który stworzy dla Ciebie czystą architekturę z dużą ilością ulepszeń wydajności domyślnie (sprawdź stronę MvcTemplate ).

Jeff Lequeux
źródło
-1

wprowadź opis obrazu tutaj

Przeprowadziłem mały eksperyment z obciążeniem VSTS z podstawowym kodem i stwierdziłem, że czas odpowiedzi ASP.NET MVC jest dwukrotnie szybszy w porównaniu z formularzami internetowymi ASP.NET. Powyżej załączony wykres z wykresem.

Możesz przeczytać ten eksperyment dotyczący testu obciążenia szczegółowo w tym artykule CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Test został przeprowadzony z poniższymi specyfikacjami przy użyciu oprogramowania do testowania obciążenia VSTS i telerik: -

Użytkownik załadował 25 użytkowników.

Czas trwania testu wynosił 10 minut.

Konfiguracja maszyny DELL 8 GB Ram, Core i3

Projekt był hostowany w usługach IIS 8.

Projekt został stworzony przy użyciu MVC 5.

Założono połączenie sieciowe LAN. Więc ten test nie uwzględnia na razie opóźnienia sieci.

Przeglądarka w teście wybrana Chrome i Internet Explorer.

Wielokrotne odczyty zostały wykonane podczas testu w celu uśrednienia nieznanych zdarzeń. W tym artykule opublikowano 7 czytań i wszystkie czytania jako czytanie 1, 2 i tak dalej.

Shivprasad Koirala
źródło
Twoja metodologia testowania jest zła i mocno stronnicza, a twoje wnioski są nieważne. Prawidłowo zbudowana aplikacja WebForms jest testowalna, ma odpowiednią separację problemów i ma minimalne obciążenie użytkowe. Chociaż MVC nie ma pętli zdarzeń cyklu życia strony, ma do czynienia z routingiem i wykonaniem widoku. Wasze artykuły na ten temat w CP są mocno stronnicze.
Richard Hauer
Prawidłowo i starannie zbudowana aplikacja nawet w najgorszej technologii zdziałaby cuda. Cykl życia strony ASP.NET zdecydowanie ma większy ładunek w porównaniu do wykonywania routingu i widoku, ponieważ dotyczy generowania interfejsu użytkownika HTML. Routing jest częścią platformy ASP.NET, więc istnieją one nawet w zwykłych formularzach internetowych. Jedna rzecz, na którą się zgadzam, jeśli nie napiszesz kodu za swoją wydajnością, będzie równoważna MVC, ale zestaw narzędzi Webform jest tak kuszący, że kod za nim staje się integralną częścią. Chociaż MVC w ogóle mi na to nie pozwala. Uwielbiam to, jak w maszynce do golenia wyłączyli widok projektu i kod.
Shivprasad Koirala