Když je v projektu příliš mnoho stránek, spustí se IIS a web je při prvním otevření velmi pomalý, protože projekt není předkompilovaný v době vydání, ale dynamicky se kompiluje při návštěvě webové stránky uživatelem. Pokud chcete zlepšit výkon svého stávajícího webu a provádět kontrolu chyb, je nutné při publikaci projektu zvolit "Předkompilovat během vydání".
Úvod
U malých projektů může publikování podle výchozích nastavení v podstatě fungovat normálně, první stránka se otevře za 56 sekund (v závislosti na konfiguraci serveru) a první otevření ostatních stránek je v podstatě dokončeno za 12 sekund, ne první okamžité otevření.
Jakmile se funkce projektu stanou složitějšími a počet souborů se zvýší, bude trvat více než 30 sekund otevřít první stránku při prvním spuštění po publikaci a přibližně 10 sekund při prvním otevření ostatních stránek, nikoli první okamžité otevření.
Je to proto, že projekt není v době vydání předkompilován, ale dynamicky se kompiluje při přístupu uživatele na webovou stránku, a jakmile je aplikační pool recyklován nebo změněny soubory projektu, bude znovu zkompilován a opět projde pomalým "prvním pokusem", což je nesnesitelné.
Výhody předkompilace
- Výkon. Kompilovaný kód se vykonává mnohem rychleji než skriptovací jazyky jako ECMAScript nebo VBScript, protože je reprezentací blíže strojovému kódu a nevyžaduje další analýzu.
- Bezpečnost. Zkompilovaný kód je obtížnější zpětně analyzovat než nekompilovaný zdrojový kód, protože postrádá čitelnost a abstrakci, kterou mají vysokoúrovňové jazyky. Navíc nástroje pro fuzzování zlepšují schopnost zkompilovaného kódu odolat zpětnému inženýrství.
- Stabilita. Zkontrolujte svůj kód na syntaxické chyby, problémy s bezpečností písma a další problémy při kompilaci. Odhalením těchto chyb při sestavování lze v kódu odstranit mnoho chyb.
- Interoperabilita. Protože kód MSIL podporuje jakýkoli .NET jazyk, je možné použít assemblery původně napsané v jiných jazycích. Například pokud píšete ASP.NET webovou stránku v C#, můžete přidat odkaz na .dll soubor napsaný ve Visual Basicu.
ASP.NET Jádro předkompilované
Předkompilováno
Předkompilace je výchozí způsob pro ASP .Net Core. Při publikování jsou všechny Razor pohledy v systému ve výchozím nastavení předkompilované. Kompilovaný pohled DLL je jednotně pojmenován xxx.PrecompiledViews.dll nebo xxx.Views.dll
Dynamická kompilace
Je snadné nastavit celý projekt na dynamickou kompilaci, stačí přidat konfigurační projekt MvcRazorCompileOnPublish s hodnotou false
ASP.NET Předběžná sestava webu
Visual Studio používáme k publikování webových stránek následujícími způsoby:
Význam možnosti "Povolit aktualizace tohoto předkompilovaného webu" Když publikujeme .Net webový projekt, obecně vše. CS souboru, který automaticky vygeneruje DLL dynamickou knihovnu odkazů, jež velmi dobře chrání zdrojový kód webu, protože serverový kód je obvykle umístěn v . Protože DLL soubory v CS souboru jsou všechny generovány a pak nahrané na server, ostatní je nemohou snadno otevřít!
Nicméně jiné soubory, jako ashx, aspx a další soubory, co v nich je, jsou takové, jaké jsou, jiné mohou tyto soubory otevřít a zobrazit je, i když jiné nevidí CS kód, ale stále vidí HTML kód nebo některé serverové ovládací prvky a související atributy v souboru ASPX; Soubor jako ashx je ekvivalentní souboru CS a kód v něm je snadno viditelný;
Proto platí . CS soubory jsou bezpečné, ale ASPX, ashx a další soubory nejsou bezpečné; Existuje tedy způsob, jak udělat webové soubory nahrané na server bezpečné? Existuje způsob, tedy při publikování nezaškrtávat "Povolit aktualizace tohoto předkompilovaného webu";
Zaškrtnout Povolit aktualizace tohoto předkompilovaného webu
Pokud při publikování webu zaškrtnete "Povolit aktualizaci tohoto předkompilovaného webu", výsledek je následující: Celý soubor webu, kromě všech CS souborů zkompilovaných do DLL souborů, jiných souborů, a původní soubor nemá žádné změny, co je uvnitř nebo co, pokud ho ostatní otevřou přes Notepad, kód, HTML kód atd. uvnitř jsou ostatním viditelné na první pohled.
Navíc, když uživatelé poprvé navštíví určitou stránku, je třeba ji zkompilovat, aby našla chyby, a pokud chyby nejsou, lze je normálně zpřístupnit, takže rychlost je relativně pomalá. Návštěvy po tom jsou normální;
Odškrtněte "Povolit aktualizace tohoto předkompilovaného webu"
Pokud při publikování webu nezaškrtnete "Povolit aktualizaci tohoto předkompilovaného webu", výsledek je následující: 1. Všechny CS soubory na webu jsou zkompilovány do DLL souborů; 2. Kromě cs souboru jsou také zkompilovány další soubory, jako ASPX, ASHX a další, a každý soubor generuje odpovídající *.compiled soubor v adresáři BIN;
Poté, pokud si přes poznámkový blok prohlížíte soubory ASPX, ASHX a další, neuvidíte v nich žádný kód, dokonce ani HTML značkování není viditelné, otevřete takový soubor, je v něm jen jeden řádek textu, obsah je "Toto je značkovací soubor generovaný předkompilovaným nástrojem, neměl by být mazán!", a velikost těchto souborů je 1kb;
Pokud se pokusíte otevřít webovou stránku, zjistíte, že kromě první stránky po zahájení projektu, která stále trvá 1~2 sekundy (bez EF), se první otevření každé druhé stránky okamžitě (první pomalost EF přesahuje rámec tohoto článku). To mě nutí cítit se, jako bych přišel pozdě, než jsem to viděl předkompilované!
Tady vám tajně říkám, že smazání adresáře Views neovlivní běžné otevření webové stránky~ Proč to nenecháte smazat, neodvážíme se ptát a neodvážíme se to smazat.
Cíl byl dosažen a bylo třeba vyřešit některé následky, například nepořádek v adresáři bin (bin directory).
Vyberte "Nespojovat". Vytvořte samostatné assemblery pro každou stránku a ovládací element", a výsledkem je mnohem více App_Web_*.dll souborů v binu.
V době vydání generuje kořen projektu soubor PrecompiledApp.config. Obsah je následující:
Soubor PrecompiledApp.config se používá ke sledování, jak je aplikace nasazena a zda ASP.NET potřeba v době žádosti zkompilovat nějaké soubory. |
Zveřejněno 22. 8. 2020 10:05:17
|
|
|
|
