2012-06-27 17 views
5

Secondo Brad Wilson, RenderAction è più lento di RenderPartial.Prestazione RenderAction vs RenderPartial

Tuttavia, qualcuno ha qualche statistica che mostra la differenza di prestazioni?

Sono in procinto di sviluppare un'applicazione in cui le pagine sono composte da "Widget".

ho due scelte:

Composizione presso il View livello

chiamata RenderAction per ciascun widget. Questo è di gran lunga l'approccio più semplice, ma significa che stiamo eseguendo un ciclo MVC completo per ciascun widget.

Composizione a livello di controller

Compose una ViewModel per la pagina che contiene i dati necessari per ciascun widget. Chiama RenderPartial per ogni widget. Questo è molto più complicato da implementare, ma significa che faremo solo un ciclo MVC.

Ho testato gli approcci di cui sopra con 3 diversi widget su una pagina e la differenza nel tempo di rendering era di 10 secondi (non vale la pena preoccuparsi).

Tuttavia, qualcuno ha ottenuto risultati di test più concreti di questo, o forse ha provato a provare entrambi gli approcci?

risposta

3

Io suggerirei altre 2 opzioni, entrambi richiedono di comporre il modello di vista a livello di controller ed entrambi possono lavorare insieme (a seconda dei dati)

  1. Html.DisplayFor() - modelli di visualizzazione
  2. Helpers tramite i metodi di estensione

L'opzione 2 funziona molto bene se si desidera mantenere quei widget in assiemi diversi, dopotutto sono solo funzioni che restituiscono una stringa. Penso che abbia anche le migliori prestazioni, ma ovviamente perdi i modelli 'designer friendly'. Penso che sia importante considerare l'aspetto della manutenibilità, non solo le prestazioni non elaborate (finché non ne hai davvero bisogno, e anche in questo caso, il caching è più utile).

Per piccole cose (data o nome di formattazione, ecc.) Userei gli helper, dal momento che l'html è di solito un intervallo con una classe, per le cose più complesse vorrei usare i modelli di visualizzazione.

+0

+1 per il suggerimento DisplayFor(). Attualmente sto delegando la responsabilità di rendering al widget in modo da chiamare semplicemente '@ widget.Render (Html)' e il widget può usare 'HtmlHelper' per renderizzare se stesso. Detto questo, posso rendere questa delegazione opzionale e chiamare semplicemente 'DisplayFor()' di default. –

3

Ho recentemente lavorato a un'applicazione che stava riscontrando problemi di prestazioni e ho trovato una vista che stava effettuando quattro chiamate a RenderAction, più un'altra nel layout. Ho scoperto che ogni chiamata a RenderAction, anche quando aggiungevo un'azione fittizia che restituiva una vista vuota, richiedeva circa 200-300 ms (sul mio computer locale). Moltiplicare per il numero di chiamate e hai un enorme successo di prestazioni nella pagina. Nel mio caso ci sono state quattro chiamate che causano circa un secondo di overhead server non necessario. In confronto, le chiamate a RenderPartial erano intorno all'area di 0-10 ms.

Eviterei di utilizzare RenderAction laddove possibile a favore di RenderPartial. Il responsabile del trattamento dovrebbe essere responsabile della restituzione di tutte le informazioni necessarie. Nel caso dei widget, se hai bisogno di più azioni per più widget, proverei a comporli in un'unica azione in modo che l'overhead di RenderAction si verifichi solo una volta, anche se il tuo sito funziona in modo adeguato li terrei separati per un design più pulito.

Modifica: Ho raccolto queste informazioni utilizzando MiniProfiler e colpendo il sito. Non è molto preciso ma mostra chiaramente le differenze.

Modifica: Come indicato da Oskar in basso, l'applicazione in questione avrebbe probabilmente un codice intensivo eseguito per ogni richiesta in global.asax. La grandezza di questo colpo dipenderà dal codice dell'applicazione, ma RenderPartial eviterà di eseguire un altro ciclo MVC del tutto.

+2

Dubito che RenderAction() sia sempre 200ms + - se RenderAction() è sempre 200ms, allora una richiesta del browser per la stessa azione "vista vuota" dovrebbe essere almeno 200ms. Ma poiché le richieste del browser in generale possono essere veloci come 10-20 ms, sembra probabile che l'applicazione in questione abbia un codice pesante (ad es. In global.asax) che viene eseguito per ogni richiesta. –

+0

@Oskar questo è vero. Da allora non ci ho lavorato, ma so che ha avuto problemi piuttosto seri. Questo è solo per illustrare che il ciclo MVC implicito che viene chiamato in 'RenderAction()' può avere una grande differenza di prestazioni nonostante appaia così simile a 'RenderPartial()'. – mao47