|
|
Veröffentlicht am 22.8.2020, 10:05:17
|
|
|
|
Wenn ein Projekt zu viele Seiten hat, startet IIS und die Website ist beim ersten Öffnen sehr langsam, da das Projekt zum Zeitpunkt der Veröffentlichung nicht vorkompiliert ist, sondern dynamisch kompiliert wird, wenn der Nutzer die Webseite besucht. Wenn Sie die Leistung Ihrer bestehenden Seite verbessern und Fehlersuche durchführen möchten, ist es notwendig, bei der Veröffentlichung Ihres Projekts "Vorkompilieren während der Veröffentlichung" auszuwählen.
Einleitung
Bei kleinen Projekten kann das Veröffentlichen gemäß den Standardeinstellungen im Grunde den normalen Betrieb erfüllen: Die erste Seite wird in 56 Sekunden geöffnet (je nach Serverkonfiguration), und das erste Öffnen der anderen Seiten ist praktisch in 12 Sekunden abgeschlossen, nicht die erste sofortige Öffnung.
Sobald die Projektfunktionen komplex werden und die Anzahl der Dateien steigt, dauert es mehr als 30 Sekunden, die erste Seite für den ersten Durchlauf nach der Veröffentlichung zu öffnen, und etwa 10 Sekunden für das erste Öffnen anderer Seiten, nicht die erste sofortige Öffnung.
Das liegt daran, dass das Projekt zum Zeitpunkt der Veröffentlichung nicht vorkompiliert ist, sondern dynamisch kompiliert wird, wenn der Benutzer die Webseite aufruft, und sobald der Anwendungspool recycelt oder die Projektdateien geändert werden, wird es erneut kompiliert und durchläuft erneut eine langsame "erste Mal", was unerträglich ist.
Vorteile der Prekompilation
- Performance. Kompilierter Code wird deutlich schneller ausgeführt als Skriptsprachen wie ECMAScript oder VBScript, da er eine Darstellung ist, die näher am Maschinencode liegt und keine zusätzliche Analyse erfordert.
- Sicherheit. Kompilierter Code ist schwieriger rückzuentwickeln als unkompilierter Quellcode, da ihm die Lesbarkeit und Abstraktion fehlen, die hochrangige Sprachen besitzen. Zusätzlich verbessern Fuzzing-Tools die Fähigkeit des kompilierten Codes, der Reverse-Engineering-Verarbeitung zu widerstehen.
- Stabilität. Überprüfe deinen Code bei der Kompilierung auf Syntaxfehler, Typsicherheitsprobleme und andere Probleme. Durch das Erkennen dieser Fehler zur Bauzeit können viele Fehler im Code eliminiert werden.
- Interoperabilität. Da MSIL-Code jede .NET-Sprache unterstützt, ist es möglich, Assemblies zu verwenden, die ursprünglich in anderen Sprachen geschrieben wurden. Wenn Sie zum Beispiel ASP.NET Webseite in C# schreiben, können Sie eine Referenz zu einer .dll Datei hinzufügen, die in Visual Basic geschrieben wurde.
ASP.NET Core vorkompiliert
Vorkompiliert
Precompilation ist der Standardweg für ASP .Net Core. Zum Zeitpunkt der Veröffentlichung sind alle Razor-Ansichten im System standardmäßig vorkompiliert. Die kompilierte View-DLL wird einheitlich xxx.PrecompiledViews.dll oder xxx.Views.dll genannt
Dynamische Kompilation
Es ist einfach, das gesamte Projekt auf dynamische Kompilierung zu konfigurieren, einfach ein Konfigurationsprojekt MvcRazorCompileOnPublish mit dem Wert false hinzuzufügen
ASP.NET Vorzusammenstellung der Website
Wir nutzen Visual Studio, um eine Website auf folgende Weise zu veröffentlichen:
Die Bedeutung der Option "Updates dieser vorkompilierten Seite erlauben" Wenn wir ein .Net-Webprojekt veröffentlichen, gilt im Allgemeinen alle . CS-Datei, die automatisch eine DLL-Dynamik-Linkbibliothek generiert, die den Quellcode der Website sehr gut schützen kann, da der serverseitige Code in der Regel in liegt. Da die DLL-Dateien in der CS-Datei alle generiert und dann auf den Server hochgeladen werden, können andere sie nicht einfach öffnen!
Andere Dateien wie ashx, aspx und andere Dateien – was darin ist, ist das, was es ist; andere können diese Dateien öffnen, um anzuzeigen, während andere den CS-Code nicht sehen können, aber dennoch den HTML-Code oder einige Serversteuerungen und zugehörige Attribute in der ASPX-Datei sehen können; Eine Datei wie Ashx entspricht einer CS-Datei, und der darin enthaltene Code ist leicht sichtbar;
Daher gilt . CS-Dateien sind sicher, aber ASPX, ashx und andere Dateien sind nicht sicher; Gibt es also eine Möglichkeit, Webdateien, die auf den Server hochgeladen werden, sicher zu machen? Es gibt eine Möglichkeit, nämlich beim Veröffentlichen nicht "Erlauben Sie Aktualisierungen dieser vorkompilierten Seite" anzukreuzen;
Überprüfen Sie Erlaubnis-Updates auf dieser vorkompilierten Seite
Wenn du beim Veröffentlichen des Webs "Erlauben zum Aktualisieren dieser vorkompilierten Seite" ankreuzt, ergibt sich das Ergebnis wie folgt: Die gesamte Website-Datei, außer allen CS-Dateien, die in DLL-Dateien kompiliert wurden, anderen Dateien und der ursprüngliche enthält keine Änderungen, was darin ist oder was, solange andere sie über Notepad öffnen, kann der Code, HTML-Code usw. von anderen auf einen Blick gesehen werden.
Außerdem müssen Benutzer, wenn sie eine bestimmte Seite zum ersten Mal besuchen, kompiliert werden, um Fehler zu finden, und wenn keine Fehler auftreten, können sie normal abgerufen werden, sodass die Geschwindigkeit relativ langsam wird. Besuche danach sind normal;
Deaktivieren Sie "Aktualisieren dieser vorkompilierten Seite erlauben"
Wenn Sie bei der Veröffentlichung des Webs nicht "Erlauben diese vorkompilierte Seite aktualisieren" aktivieren, lautet das Ergebnis wie folgt: 1. Alle CS-Dateien auf der Website werden zu DLL-Dateien kompiliert; 2. Zusätzlich zur CS-Datei werden auch weitere Dateien wie ASPX, ASHX und andere Dateien zusammen kompiliert, und jede Datei erzeugt eine entsprechende *.compiled Datei im BIN-Verzeichnis;
Danach sieht man, wenn man ASPX, ASHX und andere Dateien im Notizblock ansieht, keinen Code darin, selbst das HTML-Code-Markup ist nicht sichtbar. Öffne eine solche Datei, es gibt nur eine Textzeile darin, der Inhalt lautet: "Dies ist eine Markup-Datei, die vom vorkompilierten Tool generiert wurde, sie darf nicht gelöscht werden!", und die Größe dieser Dateien beträgt 1 kb;
Wenn Sie versuchen, eine Webseite zu öffnen, werden Sie feststellen, dass außer auf die erste Seite nach Projektbeginn, die immer noch 1~2 Sekunden dauert (kein EF), die erste Seite sofort geöffnet wird (die erste Langsamkeit von EF liegt außerhalb des Rahmens dieses Artikels). Das lässt mich das Gefühl haben, dass ich zu spät bin, um vorkompiliert zu sein!
Hier sage ich dir heimlich, dass das Löschen des Views-Verzeichnisses die normale Öffnung der Webseite nicht beeinflusst~ Warum lässt du es nicht löschen? Wir wagen es nicht zu fragen und wir wagen es auch nicht, es zu löschen.
Das Ziel wurde erreicht, und es gab einige Nachwirkungen, die behoben werden mussten, wie etwa das Durcheinander im Bin-Verzeichnis.
Wählen Sie "Nicht zusammenführen." Erstelle separate Assemblies für jede Seite und Kontrolle", und das Ergebnis ist viel mehr App_Web_*.dll Dateien im Bin.
Zum Zeitpunkt der Veröffentlichung generiert die Projektwurzel eine PrecompiledApp.config-Datei. Der Inhalt ist wie folgt:
Die Datei PrecompiledApp.config wird verwendet, um nachzuverfolgen, wie die Anwendung bereitgestellt wird und ob ASP.NET zum Zeitpunkt der Anfrage Dateien kompilieren muss. |
Vorhergehend:Erklärung der neuen Funktionen und Wissenspunkte in C# 8.0Nächster:EF DbContext garantiert, dass der Kontext eindeutig ist
|
