Når det er for mange sider i et prosjekt, starter IIS opp, og nettsiden er veldig treg når du åpner den for første gang, fordi prosjektet ikke er forhåndskompilert ved lansering, men blir dynamisk kompilert når brukeren besøker nettsiden. Hvis du ønsker å forbedre ytelsen til ditt eksisterende nettsted og utføre feilkontroll på siden, er det nødvendig å velge «Forkompilering under lansering» når du publiserer prosjektet ditt.
Introduksjon
For små prosjekter kan publisering etter standardinnstillingene i praksis oppfylle normal drift, den første siden åpnes på 56 sekunder (avhengig av serverkonfigurasjon), og den første åpningen av andre sider er i praksis fullført på 12 sekunder, ikke den første øyeblikkelige åpningen.
Når prosjektfunksjonene blir komplekse og antall filer øker, vil det ta mer enn 30 sekunder å åpne den første siden for første runde etter publisering, og omtrent 10 sekunder for første åpning av andre sider, ikke den første øyeblikkelige åpningen.
Dette er fordi prosjektet ikke er forhåndskompilert ved lansering, men blir dynamisk kompilert når brukeren får tilgang til nettsiden, og når applikasjonspoolen er resirkulert eller prosjektfilene endres, vil det bli kompilert på nytt og gå gjennom en langsom "første gang" igjen, noe som er uutholdelig.
Fordeler med prekompilering
- Ytelse. Kompilt kode kjøres mye raskere enn skriptspråk som ECMAScript eller VBScript fordi det er en representasjon nærmere maskinkode og ikke krever ytterligere analyse.
- Sikkerhet. Kompilt kode er vanskeligere å reversere enn ukompilert kildekode fordi den mangler lesbarheten og abstraksjonen som høynivåspråk har. I tillegg forbedrer fuzzing-verktøy den kompilerte kodens evne til å motstå reversering av prosessering.
- Stabilitet. Sjekk koden din for syntaksfeil, typesikkerhetsproblemer og andre problemer ved kompilering. Ved å fange opp disse feilene under byggetiden, kan mange feil elimineres i koden.
- Interoperabilitet. Siden MSIL-kode støtter alle .NET-språk, er det mulig å bruke assembler opprinnelig skrevet i andre språk i koden. For eksempel, hvis du skriver ASP.NET nettside i C#, kan du legge til en referanse til en .dll fil skrevet i Visual Basic.
ASP.NET Kjerne forhåndskompilert
Forhåndskompilert
Prekompilering er standardmetoden for ASP .Net Core. Ved publisering er alle Razor-visninger i systemet forhåndskompilert som standard. Den kompilerte visnings-DLL kalles jevnt xxx.PrecompiledViews.dll eller xxx.Views.dll
Dynamisk samling
Det er enkelt å konfigurere hele prosjektet til dynamisk kompilering, bare legg til et konfigurasjonsprosjekt MvcRazorCompileOnPublish med verdien false
ASP.NET Forhåndskompilering av nettsiden
Vi bruker Visual Studio for å publisere en nettside på følgende måter:
Betydningen av alternativet «Tillat oppdateringer til dette forhåndskompilerte nettstedet». Når vi publiserer et .Net-webprosjekt, gjelder generelt alle . CS-fil, som automatisk genererer et DLL-dynamisk lenkebibliotek, som kan beskytte kildekoden til nettstedet svært godt, fordi server-siden vanligvis plasseres i . Siden DLL-filene i CS-filen alle genereres og lastes opp til serveren, kan ikke andre enkelt åpne dem!
Men andre filer, som ashx, aspx og andre filer, det som er i dem, er hva det er, andre kan åpne disse filene for visning, selv om andre ikke kan se CS-koden, men fortsatt kan se HTML-koden eller noen serverkontroller og relaterte attributter i ASPX-filen; En fil som ashx tilsvarer en CS-fil, og koden i den er lett å se;
Derfor, . CS-filer er trygge, men ASPX, ashx og andre filer er ikke trygge; Så, finnes det en måte å gjøre webfiler som lastes opp til serveren trygge? Det finnes en måte, nemlig at når du publiserer, ikke krysser av for "Tillat oppdateringer til dette forhåndskompilerte nettstedet";
Sjekk Tillat oppdateringer til dette forhåndskompilerte nettstedet
Hvis du krysser av for «Tillat å oppdatere dette forhåndskompilerte nettstedet» når du publiserer nettet, blir resultatet slik: Hele nettsidefilen, bortsett fra alle CS-filer kompilert til DLL-filer, andre filer, og den opprinnelige har ingen endringer, hva som er inni, eller hva, så lenge andre åpner den via Notepad, kan koden, HTML-koden osv. inni sees av andre med et blikk.
I tillegg, når brukere først besøker en bestemt side, må de kompileres for å finne feil, og hvis det ikke er noen feil, kan de aksesseres som normalt, så hastigheten blir relativt lav. Besøk etter det er normalt;
Fjern haken i "Tillat oppdateringer til dette forhåndskompilerte nettstedet"
Hvis du ikke krysser av for «Tillat å oppdatere dette forhåndskompilerte nettstedet» når du publiserer nettet, blir resultatet som følger: 1. Alle CS-filer på nettstedet kompileres til DLL-filer; 2. I tillegg til cs-filen kompileres også andre filer, som ASPX, ASHX og andre filer, sammen, og hver fil genererer en tilsvarende *.kompilert fil i BIN-katalogen;
Etter det, hvis du ser ASPX, ASHX og andre filer gjennom notatblokken, vil du ikke se noen kode i dem, selv HTML-kodemarkeringen er ikke synlig, åpner du en slik fil, det er bare én tekstlinje i den, innholdet er «Dette er en markeringsfil generert av det forhåndskompilerte verktøyet, den skal ikke slettes!», og størrelsen på disse filene er 1 kb;
Hvis du prøver å åpne en nettside, vil du oppdage at bortsett fra den første siden etter at prosjektet starter, som fortsatt tar 1~2 sekunder (ingen EF), åpner første gang hver annen side umiddelbart (EFs første treghet ligger utenfor denne artikkelens rammer). Dette får meg til å føle at jeg er sent ute med å se forhåndskompilert!
Her forteller jeg deg i hemmelighet at sletting av visningskatalogen ikke vil påvirke den normale åpningen av nettsiden~ Hvorfor lar du den ikke slettes, vi tør ikke spørre, og vi tør ikke slette den.
Målet ble nådd, og det var noen ettervirkninger som måtte løses, som rotet i bin-katalogen.
Velg "Ikke slå sammen." Lag separate assemblies for hver side og kontroll», og resultatet er mye mer App_Web_*.dll filer i bin.
Ved lansering genererer prosjektroten en PrecompiledApp.config-fil. Innholdet er som følger:
PrecompiledApp.config-filen brukes til å spore hvordan applikasjonen er distribuert og om ASP.NET trenger å kompilere filer på forespørselstidspunktet. |
Publisert 22.08.2020 10:05:17
|
|
|
|
