När det finns för många sidor i ett projekt startar IIS och webbplatsen är mycket långsam när du öppnar den första gången, eftersom projektet inte är förkompilerat vid lanseringstillfället, utan dynamiskt kompileras när användaren besöker webbsidan. Om du vill förbättra prestandan på din befintliga webbplats och utföra felkontroll på din sida är det nödvändigt att välja "Prekompilera under release" när du publicerar ditt projekt.
Införandet
För små projekt kan publicering enligt standardinställningarna i princip klara normal drift, första sidan öppnas på 56 sekunder (beroende på serverkonfiguration), och första öppningen av andra sidor är i princip klar på 12 sekunder, inte den första omedelbara öppningen.
När projektfunktionerna blir komplexa och antalet filer ökar, tar det mer än 30 sekunder att öppna första sidan för första omgången efter publicering, och cirka 10 sekunder för första öppningen av andra sidor, inte den första omedelbara öppningen.
Detta beror på att projektet inte är förkompilerat vid releasetillfället, utan dynamiskt kompileras när användaren går in på webbsidan, och när applikationspoolen återvinns eller projektfilerna ändras, kommer den att kompileras om och gå igenom en långsam "första gång" igen, vilket är outhärdligt.
Fördelar med förkompilering
- Prestanda. Komplad kod körs mycket snabbare än skriptspråk som ECMAScript eller VBScript eftersom det är en representation närmare maskinkod och inte kräver ytterligare analys.
- Säkerhet. Komplad kod är svårare att bakåtutveckla än okompilerad källkod eftersom den saknar den läsbarhet och abstraktion som avancerade språk har. Dessutom förbättrar fuzzingverktyg den kompilerade kodens förmåga att motstå reverse engineering av bearbetning.
- Stabilitet. Kontrollera din kod för syntaxfel, typsäkerhetsproblem och andra problem vid kompilering. Genom att upptäcka dessa fel vid byggtiden kan många fel elimineras i koden.
- Interoperabilitet. Eftersom MSIL-kod stöder alla .NET-språk är det möjligt att använda assembler som ursprungligen skrevs i andra språk i koden. Till exempel, om du skriver ASP.NET webbsida i C# kan du lägga till en referens till en .dll fil skriven i Visual Basic.
ASP.NET Core förkompilerad
Förkompilerad
Prekompilering är standardmetoden för ASP .Net Core. Vid publiceringstillfället är alla Razor-vyer i systemet förkompilerade som standard. Den kompilerade vy-DLL kallas enhetligt xxx.PrecompiledViews.dll eller xxx.Views.dll
Dynamisk samling
Det är enkelt att konfigurera hela projektet till dynamisk kompilering, lägg bara till ett konfigurationsprojekt MvcRazorCompileOnPublish med värdet false
ASP.NET Förkompilering av webbplatsen
Vi använder Visual Studio för att publicera en webbplats på följande sätt:
Betydelsen av alternativet "Tillåt uppdateringar till denna förkompilerade webbplats" När vi publicerar ett .Net-webbprojekt, generellt gäller alla . CS-fil, som automatiskt genererar ett DLL-dynamiskt länkbibliotek, vilket kan skydda webbplatsens källkod mycket väl, eftersom serversidans kod vanligtvis placeras i . Eftersom DLL-filerna i CS-filen genereras och sedan laddas upp till servern, kan andra inte enkelt öppna dem!
Andra filer, såsom ashx, aspx och andra filer, det som finns i dem är vad det är, andra kan öppna dessa filer för att visa, även om andra inte kan se CS-koden, men ändå kan se HTML-koden eller vissa serverkontroller och relaterade attribut i ASPX-filen; En fil som ashx motsvarar en CS-fil, och koden i den kan lätt ses;
Därför gäller . CS-filer är säkra, men ASPX, ashx och andra filer är inte säkra; Så, finns det något sätt att göra webbfiler som laddas upp till servern säkra? Det finns ett sätt, det vill säga att vid publicering inte kryssa i "Tillåt uppdateringar till denna förkompilerade sida";
Kontrollera tillåt uppdateringar på denna förkompilerade sida
Om du markerar "Tillåt uppdatering av denna förkompilerade sida" när du publicerar webben, blir resultatet så här: Hela webbplatsfilen, förutom alla CS-filer som kompilerats till DLL-filer, andra filer, och originalfilen har inga ändringar, vad som finns inuti eller vad, så länge andra öppnar den via Anteckningar, kan koden, HTML-koden osv. inuti ses av andra vid en snabb blick.
Dessutom, när användare först besöker en viss sida, måste de kompileras för att hitta buggar, och om det inte finns några fel kan de nås normalt, så hastigheten blir relativt långsam. Besök efter det är normala;
Avmarkera "Tillåt uppdateringar på denna förkompilerade sida"
Om du inte markerar "Tillåt uppdatering av denna förkompilerade sida" när du publicerar webben, blir resultatet följande: 1. Alla CS-filer på webbplatsen kompileras till DLL-filer; 2. Utöver cs-filen kompileras även andra filer, såsom ASPX, ASHX och andra filer, tillsammans, och varje fil genererar en motsvarande *.kompilerad fil i BIN-katalogen;
Efter det, om du tittar på ASPX, ASHX och andra filer via anteckningsblocket, kommer du inte att se någon kod i dem, inte ens HTML-kodmarkeringen syns, öppna en sådan fil, det finns bara en textrad i den, innehållet är "Detta är en markeringsfil genererad av det förkompilerade verktyget, den ska inte raderas!", och storleken på dessa filer är 1 kb;
Om du försöker öppna en webbsida kommer du att upptäcka att förutom första sidan efter att projektet startat, vilket fortfarande tar 1~2 sekunder (ingen EF), öppnas första gången varje annan sida omedelbart (EF:s första långsamhet ligger utanför denna artikels omfattning). Det får mig att känna att jag är sen med att se förkompilerat!
Här säger jag i hemlighet att radering av Views-katalogen inte påverkar den normala öppningen av webbsidan~ Varför låter du den inte raderas, vi vågar inte fråga, och vi vågar inte ta bort den.
Målet uppnåddes, och det fanns några efterverkningar som behövde lösas, som röran i bin-katalogen.
Välj "Ej slå ihop." Skapa separata assemblies för varje sida och kontroll", och resultatet blir mycket mer App_Web_*.dll filer i bin.
Vid releasen genererar projektets rot en PrecompiledApp.config-fil. Innehållet är som följer:
PrecompiledApp.config-filen används för att spåra hur applikationen distribueras och om ASP.NET behöver kompilera några filer vid förfrågan. |
Publicerad den 2020-8-22 10:05:17
|
|
|
|
