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.

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 ...

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.

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ń.

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.

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.

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.

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.

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.

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?

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.

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.

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?

MVC4

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

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.

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 ).

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.