Når der er for mange sider i et projekt, starter IIS op, og hjemmesiden er meget langsom, når du åbner den første gang, fordi projektet ikke er forudkompileret ved udgivelsestidspunktet, men dynamisk kompileres, når brugeren besøger websiden. Hvis du vil forbedre ydeevnen på din eksisterende side og udføre fejlkontrol på din side, er det nødvendigt at vælge "Prekompilér under udgivelsen", når du udgiver dit projekt.
Indførelsen
For små projekter kan udgivelse efter standardindstillingerne stort set opfylde normal drift; den første side åbnes på 56 sekunder (afhængigt af serverkonfigurationen), og den første åbning af andre sider er stort set færdig på 12 sekunder, ikke den første øjeblikkelige åbning.
Når projektfunktionerne bliver komplekse, og antallet af filer stiger, vil det tage mere end 30 sekunder at åbne den første side til første gennemgang efter udgivelse, og cirka 10 sekunder til første åbning af andre sider, ikke den første øjeblikkelige åbning.
Dette skyldes, at projektet ikke er forudkompileret ved udgivelsestidspunktet, men dynamisk kompileres, når brugeren tilgår websiden, og når applikationspoolen er genbrugt, eller projektfilerne ændres, vil den blive genkompileret og gennemgå en langsom "første gang" igen, hvilket er utåleligt.
Fordele ved prækompilering
- Præstation. Kompileret kode udføres meget hurtigere end scriptsprog som ECMAScript eller VBScript, fordi det er en repræsentation, der ligger tættere på maskinkode og ikke kræver yderligere analyse.
- Sikkerhed. Komppileret kode er sværere at reverse-engineere end ukompileret kildekode, fordi den mangler læsbarhed og abstraktion, som højniveausprog har. Derudover forbedrer fuzzing-værktøjer den kompilerede kodes evne til at modstå reverse engineering af behandling.
- Stabilitet. Tjek din kode for syntaksfejl, tryksikkerheden og andre problemer under kompilering. Ved at opdage disse fejl under byggetiden kan mange fejl elimineres i koden.
- Interoperabilitet. Da MSIL-kode understøtter ethvert .NET-sprog, er det muligt at bruge assemblies, der oprindeligt er skrevet i andre sprog, i koden. For eksempel, hvis du skriver ASP.NET webside i C#, kan du tilføje en reference til en .dll-fil skrevet i Visual Basic.
ASP.NET Core forudkompileret
Forudkompileret
Prekompilering er standardmetoden for ASP .Net Core. Ved udgivelse er alle Razor-visninger i systemet som standard forudkompilerede. Den kompilerede visnings-DLL kaldes ensartet xxx.PrecompiledViews.dll eller xxx.Views.dll
Dynamisk kompilering
Det er nemt at konfigurere hele projektet til dynamisk kompilering, bare tilføj et konfigurationsprojekt MvcRazorCompileOnPublish med værdien false
ASP.NET Forsamling af hjemmesiden
Vi bruger Visual Studio til at udgive en hjemmeside på følgende måder:
Betydningen af "Tillad opdateringer til dette forudkompilerede site"-muligheden Når vi udgiver et .Net-webprojekt, gælder det generelt alle . CS-fil, som automatisk genererer et DLL-dynamisk linkbibliotek, som kan beskytte hjemmesidens kildekode meget godt, fordi server-side koden generelt placeres i . Da DLL-filerne i CS-filen alle genereres og derefter uploades til serveren, kan andre ikke nemt åbne dem!
Dog er andre filer, såsom ashx, aspx og andre filer, hvad der er i dem, som det er; andre kan åbne disse filer for at se dem, selvom andre ikke kan se CS-koden, men stadig kan se HTML-koden eller nogle serverkontroller og relaterede attributter i ASPX-filen; En fil som ashx svarer til en CS-fil, og koden i den kan let ses;
Derfor gælder . CS-filer er sikre, men ASPX, ashx og andre filer er ikke sikre; Så, er der en måde at gøre webfiler, der uploades til serveren, sikre? Der er en måde, nemlig at ved publicering ikke sætte krydset ved "Tillad opdateringer til dette prækompilerede site";
Tjek Tillad opdateringer på denne forudkompilerede side
Hvis du markerer "Tillad opdatering af dette prækompilerede site" ved publicering af nettet, så er resultatet sådan her: Hele websitefilen, undtagen alle CS-filer kompileret til DLL-filer, andre filer, og den oprindelige har ingen ændringer, hvad der er indeni, eller hvad, så længe andre åbner den via Notepad, kan koden, HTML-koden osv. inde ses af andre med et hurtigt blik.
Derudover skal brugerne, når de først besøger en bestemt side, kompileres for at finde fejl, og hvis der ikke er nogen fejl, kan de tilgås normalt, så hastigheden bliver relativt langsom. Besøg efter det er normalt;
Fjern markeringen i "Tillad opdateringer til denne forudkompilerede side"
Hvis du ikke markerer "Tillad opdatering af dette prækompilerede site" ved publicering af webben, er resultatet som følger: 1. Alle CS-filer på hjemmesiden er kompileret til DLL-filer; 2. Ud over cs-filen kompileres andre filer, såsom ASPX, ASHX og andre filer, også sammen, og hver fil genererer en tilsvarende *.kompileret fil i BIN-mappen;
Derefter, hvis du ser ASPX, ASHX og andre filer gennem notesblokken, vil du ikke se nogen kode i dem, selv HTML-kode-markupen er ikke synlig, åbn sådan en fil, der er kun én linje tekst i den, indholdet er "Dette er en markup-fil genereret af det forudkompilerede værktøj, den bør ikke slettes!", og størrelsen på disse filer er 1kb;
Hvis du prøver at åbne en hjemmeside, vil du opdage, at bortset fra den første side efter projektets start, som stadig tager 1~2 sekunder (ingen EF), åbner hver anden side sig øjeblikkeligt (EF's første langsomhed ligger uden for denne artikels rammer). Det får mig til at føle, at jeg er sent ude til at se forudkompileret!
Her fortæller jeg dig i hemmelighed, at sletning af Views-mappen ikke vil påvirke den normale åbning af websiden~ Hvorfor lader du den ikke blive slettet, vi tør ikke spørge, og vi tør heller ikke slette den.
Målet blev opnået, og der var nogle eftervirkninger, der skulle løses, såsom rodet i bin-kataloget.
Vælg "Må ikke flettes." Opret separate assemblies for hver side og kontrol", og resultatet er meget mere App_Web_*.dll filer i bin.
På udgivelsestidspunktet genererer projektets rod en PrecompiledApp.config-fil. Indholdet er som følger:
PrecompiledApp.config-filen bruges til at spore, hvordan applikationen er deployeret, og om ASP.NET skal kompilere filer på tidspunktet for anmodningen. |
Opslået den 22-8-2020 kl. 10:05:17
|
|
|
|
