Ho trovato alcune osservazioni selvagge che ASP.NET MVC è 30 volte più veloce di ASP.NET WebForms. Qual è la differenza di prestazioni reale, è stata misurata e quali sono i vantaggi in termini di prestazioni.

Questo per aiutarmi a considerare il passaggio da ASP.NET WebForms a ASP.NET MVC.

Non abbiamo eseguito il tipo di test di scalabilità e prestazioni necessari per trarre conclusioni. Penso che ScottGu possa aver discusso dei potenziali obiettivi di prestazione. Man mano che ci spostiamo verso Beta e RTM, effettueremo internamente più test delle prestazioni. Tuttavia, non sono sicuro di quale sia la nostra politica sulla pubblicazione dei risultati dei test di prestazione.

In ogni caso, tali test devono davvero considerare le applicazioni del mondo reale ...

Penso che questa sarà una domanda difficile a cui rispondere in modo definitivo poiché molto dipenderà da A) come implementerai l'applicazione WebForms e B) come implementerai l'applicazione MVC. Nei loro formati "grezzi", MVC è probabilmente più veloce di WebForms, ma anni e anni di strumenti ed esperienza hanno prodotto una serie di tecniche per la creazione di applicazioni WebForms veloci. Sarei disposto a scommettere che uno sviluppatore ASP.NET senior potrebbe produrre un'applicazione WebForms che rivaleggia con la velocità di qualsiasi applicazione MVC, o almeno raggiungere una differenza trascurabile.

La vera differenza, come suggerito da @tvanfosson , è nella testabilità e nel SoC pulito. Se il miglioramento delle prestazioni è la tua preoccupazione principale, non penso sia un ottimo motivo per saltare la nave su WebForms e iniziare a ricostruire in MVC. Almeno fino a quando non avrai provato le tecniche disponibili per l'ottimizzazione dei WebForm.

Ha ridotto una delle mie pagine da 2MB a 200k, semplicemente eliminando il viewstate e rendendo sopportabile a livello di programmazione lavorare con l'output inviato.

La sola dimensione, anche se l'elaborazione è stata la stessa, creerà enormi miglioramenti nelle connessioni al secondo e nella velocità delle richieste.

Penso che molte delle persone che pensano che i WebForm siano intrinsecamente lenti o che richiedono molte risorse stiano mettendo la colpa nel posto sbagliato. 9 volte su 10 quando vengo chiamato per ottimizzare un'app di moduli web, ci sono troppi posti in cui gli autori delle app fraintendono lo scopo del viewstate. Non sto dicendo che il viewstate sia perfetto o altro, ma è troppo facile abusarne, ed è questo abuso che sta causando il campo di viewstate gonfio.

Questo articolo è stato prezioso per aiutarmi a capire molti di questi abusi. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Per fare un confronto valido tra MVC e WebForms dobbiamo essere sicuri che entrambe le app utilizzino correttamente le architetture.

I miei test mostrano qualcosa tra 2x e 7 volte più req / sec su MVC, ma dipende da come costruisci la tua app webforms. Con solo il testo "ciao mondo" su di esso, senza alcun controllo lato server, mvc è circa il 30-50% più veloce.

Per me il vero miglioramento delle "prestazioni" in MVC è l'aumento della superficie testabile dell'applicazione. Con WebForms c'erano molte applicazioni difficili da testare. Con MVC la quantità di codice che diventa testabile sostanzialmente raddoppia. Fondamentalmente tutto ciò che non è facilmente testabile è il codice che genera il layout. Tutta la logica aziendale e la logica di accesso ai dati, inclusa la logica che popola i dati effettivi utilizzati nella vista, è ora suscettibile di test. Anche se mi aspetto che sia anche più performante - il ciclo di vita della pagina è notevolmente semplificato e più adatto alla programmazione web - anche se fosse lo stesso o un po 'più lento varrebbe la pena passare da una prospettiva di qualità.

Penso che il problema qui sia che non importa quanto sia più veloce ASP.Net MVC rispetto ai vecchi webform, non farà la differenza, perché la maggior parte del tempo impiegato è nel database. Il più delle volte, i tuoi server web saranno seduti allo 0-10% di utilizzo della CPU solo in attesa del tuo server database. A meno che tu non ottenga un numero estremamente elevato di visite sul tuo sito web e il tuo database sia estremamente veloce, probabilmente non noterai una grande differenza.

Gli unici numeri concreti che posso trovare che provengono dallo sviluppo iniziale di ASP.NET MVC sono su questo thread del forum:

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

Lo stesso Rob Connery conferma in qualche modo l'affermazione secondo cui ScottGu ha affermato che ASP.NET MVC può servire 8000 richieste al secondo.

Forse Jeff e la sua troupe possono dare qualche suggerimento dal loro sviluppo di questo sito.

Contrariamente all'opinione accettata, l'utilizzo ottimizzato dei moduli web uccide completamente MVC in termini di prestazioni grezze. Webforms è stato iper-ottimizzato per il compito di servire html molto più a lungo di MVC.

Le metriche sono disponibili su http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Ogni singolo mvc di confronto si trova nelle classifiche inferiore-media / inferiore-superiore dell'elenco, mentre l'utilizzo di moduli web ottimizzati si colloca nelle classifiche superiore-centrale / superiore-inferiore.

Convalida aneddotica ma molto seria di queste metriche, www.microsoft.com è servito da moduli web non MVC. Qualcuno qui crede che non avrebbe scelto MVC se fosse stato empiricamente più veloce?

Non c'è davvero modo di rispondere a questo. MVC utilizza il motore di visualizzazione Web Form per impostazione predefinita e può essere configurato per utilizzare un numero qualsiasi di motori di visualizzazione personalizzati, quindi se si desidera un confronto delle prestazioni è necessario essere più specifici.

Ho iniziato a lavorare in MVC circa un anno fa, sono stato ispirato ma non colpito.

Detesto lo stato di visualizzazione e lo vedo come la radice di tutti i mali in termini di ASP.NET. Questo è il motivo per cui non lo uso e ad essere perfettamente onesto perché dovresti?

Ho preso fondamentalmente il concetto di ASP.NET MVC Framework e l'ho costruito a modo mio. Ho cambiato un paio di cose però. Ho creato il codice di wrapping del controller o il codice di routing dell'URL attorno alla ricompilazione dinamica.

Ora, vorrei arrivare a dire che le applicazioni ASP.NET MVC saranno più veloci in base a come le usi. Se abbandoni completamente WebForms sarai più veloce perché il ciclo di vita di ASP.NET e il modello a oggetti sono enormi.

Quando scrivi, crei un'istanza di un esercito ... no aspetta, una legione di oggetti che parteciperanno al rendering della tua vista. Questo sarà più lento rispetto a dove esprimere la quantità minima di comportamento nella pagina ASPX stessa. (Non mi interessa l'astrazione del motore di visualizzazione perché il supporto per le pagine ASPX in Visual Studio è decente, ma ho completamente abbandonato WebForms come concetto e fondamentalmente qualsiasi framework ASP.NET a causa del codice gonfio o dell'impossibilità di modificare il cose che collegano la mia applicazione).

Ho trovato il modo di fare affidamento sulla ricompilazione dinamica (System.Reflection.Emit) per l'emissione di oggetti e codice per scopi speciali quando necessario. L'esecuzione di questo codice è più veloce della reflection ma inizialmente costruita tramite il servizio di reflection. Questo ha dato al mio framework in stile MVC ottime prestazioni ma anche tipizzato in modo molto statico. Non uso stringhe e raccolte di coppie nome / valore. Invece i miei servizi di compilazione personalizzati vanno in una riscrittura di un modulo post in un'azione del controller che viene passata un tipo di riferimento. Dietro le quinte stanno succedendo molte cose ma questo codice è veloce, molto più veloce di WebForms o MVC Framework.

Inoltre, non scrivo URL, scrivo espressioni lambda che vengono tradotte in URL che in seguito indicano quale azione del controller richiamare. Non è particolarmente veloce, ma batte avere URL non funzionanti. È come se avessi risorse digitate staticamente e oggetti digitati staticamente. Un'applicazione web di tipo statico? Questo è quello che voglio!

Incoraggerei più persone a provarlo.

I progetti realizzati con visual studio. Uno è il modello mvc4, un altro è WebForm (tranditional). E quando si effettua un test di carico con WCAT, questo è il risultato,

MVC4 è piuttosto lento rispetto a WebForm, qualche idea?

MVC4

• potrebbe ottenere circa 11 rps
• rps è piuttosto basso sia per server da 2 cpu che da 4 cpu

WebForms (aspx)

• potrebbe superare i 2500 rps

• il killer delle prestazioni è stato scoperto che è un bug di MVC Bata o RC. E le prestazioni sarebbero migliorate una volta rimosso le cose dei bundle. Ora l'ultima versione ha risolto questo problema.

Le prestazioni dipendono da ciò che stai facendo ... Di solito MVC è più veloce di asp.net principalmente perché Viewstate è assente e perché MVC funziona di più con Callback che Postback per impostazione predefinita.

Se ottimizzi la tua pagina webform puoi avere le stesse prestazioni di MVC ma richiederà molto lavoro.

Inoltre, ci sono molti nuget per MVC (e anche per Webform) per aiutarti a migliorare le prestazioni del sito web come combinare e minimizzare i tuoi css e javascript, raggruppare le tue immagini e usarle come sprite e così via.

Le prestazioni del sito web dipendono in gran parte dalla tua architettura. Uno pulito con una buona separazione delle preoccupazioni ti offrirà un codice più pulito e un'idea migliore di come migliorare le prestazioni.

Puoi dare un'occhiata a questo modello " Neos-SDI MVC Template " che creerà per te un'architettura pulita con molti miglioramenti delle prestazioni per impostazione predefinita (controlla il sito Web MvcTemplate ).

Ho eseguito un piccolo esperimento di test di carico VSTS con del codice di base e ho riscontrato che il tempo di risposta di ASP.NET MVC è due volte più veloce rispetto a ASP.NET Webforms. Sopra è il grafico allegato con la trama.

Puoi leggere questo esperimento di test di carico in dettaglio da questo articolo CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Il test è stato condotto con le specifiche seguenti utilizzando VSTS e il software di test di carico telerik: -

Carico utente 25 utenti.

La durata del test è stata di 10 minuti.

Configurazione macchina DELL 8 GB Ram, Core i3

Il progetto è stato ospitato in IIS 8.

Il progetto è stato creato utilizzando MVC 5.

È stata presunta una connessione LAN di rete. Quindi questo test non tiene conto del ritardo di rete per ora.

Il browser nel test ha selezionato Chrome e Internet Explorer.

Letture multiple sono state prese durante il test per calcolare la media di eventi sconosciuti. 7 letture dove sono state effettuate e tutte le letture sono pubblicate in questo articolo come letture 1, 2 e così via.