Im vorherigen Artikel gibt es ein weiteres Legacy-Problem, das noch nicht gelöst wurde, nämlich ASP.NET MVC MapRoute .htm nicht funktioniert – wie löst man es, wenn man runAllManagedModulesForAllRequests="true" nicht verwendet? Später fand ich eine Lösung:
Referenz: ASP.NET MVC: Leiten Sie eine .html Anfrage an eine MVC-Route weiter.
Ich habe erläutert, warum man versuchen sollte, runAllManagedModulesForAllRequests="true" nicht zu verwenden, und dann habe ich zwei verwandte Artikel gefunden:
Die Kunst der Einfachheit: Optimieren Sie die Leistung Ihrer Webanwendungen: Verwenden Sie nicht runAllManagedModulesForAllRequests="true".
Verwenden Sie nicht runAllManagedModulesForAllRequests="true", wenn Sie Ihr MVC-Routing zum Laufen bringen
Auszug aus einer Beschreibung im Text:
Diese dringend empfohlene Lösung kann weitere Probleme verursachen. Diese Probleme entstehen darin, dass alle registrierten HTTP-Module bei jeder Anfrage laufen, nicht nur bei verwalteten Anfragen (z. B. .aspx). Das bedeutet, dass Module auf jedem .jpg .gif .css .html .pdf usw. laufen.
runAllManagedModulesForAllRequests ist wie ein Kanalschalter für IIS-Module und Anfragen; wenn dieser Switch eingeschaltet wird, gehen alle Anfragen, die auf diese Seite zugreifen, in Modules zur Verarbeitung, einschließlich einiger statischer Dateianfragen, die auch die häufigste Art von "keine Bearbeitungs"-Anfragen sind, da die Anfrage in Module eintritt, dann muss es ein entsprechendes Programm geben, das sie verarbeitet. Das verursacht unnötigen Performance-Overhead, da statische Dateien nur zur Darstellung gedacht sind, Module überhaupt nicht verarbeitet werden müssen, kleine Standorte keine Rolle spielen, wenn einige große PV-Standorte dasselbe tun, verursacht das einen gewissen "Druck" auf die Programmverarbeitung von IIS-Modulen, und die oben in einem Blogbeitrag zusammengefasste Schlussfolgerung ist Verschwendung (Verschwendung... ) und Potenzial (Potenzial... ）。
Lassen Sie uns einen Test mit Application_BeginRequest machen, um zu sehen, welche Anfragen für verschiedene Konfigurationen von runAllManagedModulesForAllRequests protokolliert werden, und den Beispielcode testen:
runAllManagedModulesForAllRequests="fasle", data.txt log:
http://localhost:55127/
http://localhost:55127/bundles/test2?v=2Fz3B0iizV2NnnamQFrx-NbYJNTFeBJ2GM05SilbtQU1
http://localhost:55127/bundles/test1?v=MDbdFKJHBa_ctS5x4He1bMV0_RjRq8jpcIAvPpKiN6U1
runAllManagedModulesForAllRequests="true", data.txt Datensatz:
http://localhost:55127/
http://localhost:55127/bundles/test2?v=2Fz3B0iizV2NnnamQFrx-NbYJNTFeBJ2GM05SilbtQU1
http://localhost:55127/bundles/test1?v=MDbdFKJHBa_ctS5x4He1bMV0_RjRq8jpcIAvPpKiN6U1
http://localhost:55127/Content/logo_small_1.gif
http://localhost:55127/Content/logo_small_4.gif
http://localhost:55127/Content/logo_small_2.gif
http://localhost:55127/Content/logo_small_3.gif
logo_small_* Das Bild ist das, was ich in der Ansicht hinzugefügt habe, das ist einfach eine Anfrage, ein statisches Bild zu testen. Wenn du auf einer großen Seite bist, füge den Testcode hinzu und aktualisiere dann die Seite, du wirst feststellen, dass es viele bedeutungslose Anfragen gibt. Vielleicht schauen Sie sich den obigen Testdatensatz an, der scheint kein Problem zu erklären, aber stellen Sie sich vor, wenn eine Seite viele statische Dateien hat, die Anzahl der Besuche zig Millionen beträgt und die Seite viele Seiten enthält, obwohl es ein kleines Problem ist, wird es unendlich vergrößert, und schließlich stellt man fest, dass es nur ein Konfigurationsproblem ist.
Das war's, ich werde den Code ändern.
|
Veröffentlicht am 13.10.2016 15:02:09
|
|
|
