Leistungsengpass Url.Action - kann ich umgehen?

8

Ich habe eine Anwendung, die ich kürzlich von ASP.NET MVC1 auf ASP.NET MVC4 rc1 aktualisiert habe.

Es verwendet die Webforms Viewengine.

Es treten Leistungsprobleme auf, wenn Url.Action (Aktion, Controller) verwendet wird.

Ich kann das Problem in ASP.NET MVC3 reproduzieren.

Ich brauche 3ms, um Ansichten darzustellen, die 10 Instanzen des Url.Action-Helfers in ASP.NET MVC1 enthalten, und 40 ms, um dieselben in ASP.NET MVC3 zu rendern.

Ich habe bereits einige Möglichkeiten gefunden, um es schneller rendern zu lassen:

  • Ich habe die Standardroute nach oben verschoben

  • Ich habe Url.Action entfernt und statische Links verwendet

Das fühlt sich nicht richtig an: Die Anwendung ist ziemlich groß und ich brauche die Güte eines ordentlichen Arbeits-Routings. Ich bin auch nicht zuversichtlich, dass ich alle Leistungsengpässe gefunden habe. Routing ist ein zentraler Teil von MVC: Wenn etwas schlecht läuft, wird es in verschiedenen Teilen der Anwendung angezeigt.

Ich habe den Eindruck, dass MVC3 einige Routing-Funktionen (wie Regex-Constraints) eingeführt hat, die, selbst wenn ich sie nicht verwende, zu einer schlecht funktionierenden Anwendung führen.

Gibt es etwas, das ich tun kann, wie Features von Routing zu ändern oder einen anderen Satz von URL-Helfern zu verwenden?

Dieser Code reproduziert das Problem:

Indexaktion

%Vor%

index.aspx

%Vor%

Routenregistrierung Das sieht komisch aus: aber ich möchte nur mein nicht sehr kompliziertes Routing simulieren. Dies sind nicht die 600 Routen von SO!

%Vor%

BEARBEITEN

Der Beispielcode wurde jetzt gegen MVC2 kompiliert. In VS2010 kann MVC2 gegen .NET 3.5 oder 4.0 kompiliert werden.

Die Leistung mit 3.5 ist gut und 4.0 ist schlecht.

Ich denke, das bedeutet, dass der schlecht funktionierende Teil nicht in einer MVC-Assembly, sondern in einer Framework-Assembly (wie System.Web.Routing.dll) ist. Die Frage ist immer noch die gleiche: Kann ich etwas dagegen tun? Eine akzeptierte Antwort wäre auch: Nein, der Code ist langsam, weil von Version 3.5 zu 4.0 MS XXX

geändert hat

EDIT-2

Ich habe den Teil von System.Web.Routing.dll dekompiliert, der zu lange dauert. Es verwendet einen kompilierten regulären Ausdruck. Es gibt einen Code-Pfad (constraint2.Match), der ohne Ausführung der Regex zurückkehrt, aber ich habe noch nicht überprüft, ob er intern eine andere teure Operation verwendet.

%Vor%     
Mathias F 09.08.2012, 21:38
quelle

3 Antworten

3

Es gibt ein ähnliches Problem wie Ihres: Erster Aufruf von Url.Action auf einer Seite ist langsam Es gibt Schlussfolgerungen über Routing-Einschränkungen mit Regexp-Einschränkungen, die sehr langsam sind.

    
Kirill Bestemyanov 17.08.2012, 21:56
quelle
0

Jede Ansicht wird kompiliert und zwischengespeichert, wenn sie das erste Mal verwendet wird. Da die aspx-Ansichten jedoch nicht speziell für Mvc entworfen wurden, wird jede URL-Aktion im letzten Link nicht ein für allemal kompiliert, sondern bei jeder Ausführung neu berechnet. Razor Compiler hat eine bessere Optimierung. Die einzige Lösung besteht darin, die verschiedenen Verknüpfungen mit Url.Action zu berechnen und sie in einer Eigenschaft auf Anwendungsebene zu speichern, sodass sie nur bei der ersten Ausführung berechnet wird. Sie können sie entweder in das Anwendungswörterbuch oder in statische Eigenschaften einer Klasse einfügen.

    
Francesco Abbruzzese 14.08.2012 08:17
quelle
0

Ich bin mir nicht sicher, was das ist, was Sie sehen, aber es kann nicht nur ein MVC 1 gegen MVC 4 sein, das IIS-Setup in späteren Versionen kann die Geschwindigkeit der Ansichtsdarstellung beeinflussen. Ich bin vor einigen Monaten auf einen Diaprojektor gestoßen, den ich für sehr interessant hielt, in Bezug auf Tipps zur Leistungsverbesserung in MVC 3-Apps.

Ссылка

Sehen Sie sich insbesondere Folie 28 an, die besagt:

  

Deinstallieren Sie das IIS UrlRewrite-Modul

     
  • Wenn keine Anwendungen auf dem Server es verwenden
  •   
  • Kein Effekt in MVC-Apps vor v3
  •   
  • Verbessert die Geschwindigkeit der URL-Generierung
  •   

Ich nehme an, dass das UrlRewrite-Modul sich negativ auf MVC 3 auswirken wird, aber nicht auf MVC 2 oder 1, was eine Quelle der Verlangsamung sein könnte, die Sie sehen. Es gibt noch einige andere Verbesserungen, aber ich glaube nicht, dass sich irgendwelche von ihnen direkt auf das beziehen, was Sie sehen.

    
Tommy 14.08.2012 13:56
quelle