Wanneer er te veel pagina's in een project staan, start IIS op en is de website erg traag als je hem voor het eerst opent, omdat het project niet vooraf gecompileerd is op het moment van release, maar dynamisch wordt gecompileerd wanneer de gebruiker de webpagina bezoekt. Als je de prestaties van je bestaande site wilt verbeteren en foutcontrole wilt uitvoeren, is het noodzakelijk om "Precompileren tijdens release" te selecteren wanneer je je project publiceert.
Introductie
Voor kleine projecten kan publiceren volgens de standaardinstellingen in principe voldoen aan de normale werking: de eerste pagina wordt geopend in 56 seconden (afhankelijk van de serverconfiguratie), en het eerste openen van andere pagina's is in principe voltooid in 12 seconden, niet de eerste directe opening.
Zodra de projectfuncties complex worden en het aantal bestanden toeneemt, duurt het meer dan 30 seconden om de eerste pagina te openen voor de eerste run na publicatie, en ongeveer 10 seconden voor het eerste openen van andere pagina's, niet de eerste directe opening.
Dit komt doordat het project niet vooraf gecompileerd is op het moment van release, maar dynamisch wordt gecompileerd wanneer de gebruiker de webpagina opent, en zodra de applicatiepool is gerecycled of de projectbestanden zijn gewijzigd, wordt het opnieuw gecompileerd en doorloopt het opnieuw een langzame "eerste keer", wat ondraaglijk is.
Voordelen van precompilatie
- Prestatie. Gecompileerde code wordt veel sneller uitgevoerd dan scripttalen zoals ECMAScript of VBScript, omdat het een representatie is die dichter bij machinecode ligt en geen extra analyse vereist.
- Beveiliging. Gecompileerde code is moeilijker te reverse-engineeren dan niet-gecompileerde broncode omdat het de leesbaarheid en abstractie mist die hoog-niveau talen hebben. Daarnaast verbeteren fuzzing-tools het vermogen van de gecompileerde code om reverse-engineering verwerking te weerstaan.
- Stabiliteit. Controleer je code op syntaxisfouten, typeveiligheidsproblemen en andere problemen tijdens het compileren van de code. Door deze fouten tijdens het bouwen te ontdekken, kunnen veel fouten in de code worden geëlimineerd.
- Interoperabiliteit. Omdat MSIL-code elke .NET-taal ondersteunt, is het mogelijk om assemblies te gebruiken die oorspronkelijk in andere talen zijn geschreven in de code. Als je bijvoorbeeld ASP.NET webpagina in C# schrijft, kun je een referentie toevoegen aan een .dll bestand dat in Visual Basic is geschreven.
ASP.NET Core vooraf gecompileerd
Vooraf samengesteld
Precompilatie is de standaardmethode voor ASP .Net Core. Bij publicatie zijn alle Razor-weergaven in het systeem standaard vooraf gecompileerd. De gecompileerde weergave DLL wordt uniform xxx.PrecompiledViews.dll of xxx.Views.dll genoemd
Dynamische compilatie
Het is eenvoudig om het hele project te configureren voor dynamische compilatie, voeg gewoon een configuratieproject toe MvcRazorCompileOnPublish met de waarde false
ASP.NET Voorcompilatie van de website
We gebruiken Visual Studio om een website op de volgende manieren te publiceren:
De betekenis van de optie "Sta updates toe aan deze vooraf gecompileerde site". Wanneer we een .Net-webproject publiceren, geldt in het algemeen voor alle . CS-bestand, dat automatisch een DLL-dynamische linkbibliotheek genereert, die de broncode van de website zeer goed kan beschermen, omdat de server-side code meestal in wordt geplaatst. Omdat de DLL-bestanden in het CS-bestand allemaal worden gegenereerd en vervolgens naar de server worden geüpload, kunnen anderen ze niet gemakkelijk openen!
Andere bestanden, zoals ashx, aspx en andere bestanden, wat erin staat, is wat het is; anderen kunnen deze bestanden openen om te bekijken, hoewel anderen de CS-code niet kunnen zien, maar toch de HTML-code of sommige serverbesturingselementen en gerelateerde attributen in het ASPX-bestand kunnen zien; Een bestand als Ashx is gelijkwaardig aan een CS-bestand, en de code daarin is gemakkelijk te zien;
Daarom geldt . CS-bestanden zijn veilig, maar ASPX, ashx en andere bestanden zijn niet veilig; Dus, is er een manier om webbestanden die naar de server worden geüpload veilig te maken? Er is een manier, namelijk bij het publiceren, niet aanvinken "Toestaan van updates aan deze vooraf gecompileerde site";
Controleer Toestaan van updates op deze vooraf samengestelde site
Als je bij het publiceren van het web "Toestaan om deze vooraf gecompileerde site bij te werken" aanvinkt, is het resultaat als volgt: Het hele websitebestand, behalve alle CS-bestanden die zijn gecompileerd in DLL-bestanden, andere bestanden, en het originele bestand heeft geen wijzigingen, wat er binnenin zit of wat, zolang anderen het via Notepad openen, de code, HTML-code, enzovoort kan door anderen in één oogopslag worden gezien.
Bovendien moeten gebruikers bij het bezoeken van een bepaalde pagina worden gecompileerd om bugs te vinden, en als er geen fouten zijn, kunnen ze normaal worden benaderd, waardoor de snelheid relatief traag wordt. Bezoeken daarna zijn normaal;
Vink "Toestaan van updates aan deze vooraf gecompileerde site" uit
Als je bij het publiceren van het web niet "Toestaan om deze vooraf gecompileerde site bij te werken" aanvinkt, is het resultaat als volgt: 1. Alle CS-bestanden op de website worden gecompileerd tot DLL-bestanden; 2. Naast het cs-bestand worden ook andere bestanden, zoals ASPX, ASHX en andere bestanden, samen gecompileerd, en genereert elk bestand een overeenkomstig *.gecompileerd bestand in de BIN-map;
Daarna, als je ASPX, ASHX en andere bestanden via het notitieblok bekijkt, zie je geen code meer in, zelfs de HTML-code-opmaak is niet zichtbaar, open zo'n bestand, er staat maar één regel tekst in, de inhoud is "Dit is een markupbestand dat door de vooraf gecompileerde tool is gegenereerd, het mag niet verwijderd worden!", en de grootte van deze bestanden is 1 kb;
Als je probeert een webpagina te openen, zul je merken dat, behalve de eerste pagina na het projectstart, die nog steeds 1~2 seconden duurt (geen EF), de eerste keer dat elke andere pagina direct opengaat (de eerste traagheid van EF valt buiten het bestek van dit artikel). Dit geeft me het gevoel dat ik te laat ben om vooraf gecompileerd te zijn!
Hier vertel ik je stiekem dat het verwijderen van de Views-map geen invloed heeft op het normale openen van de webpagina~ Waarom laat je het niet verwijderen, we durven het niet te vragen, en we durven het niet te verwijderen.
Het doel was bereikt, en er waren enkele na-effecten die moesten worden opgelost, zoals de rommel in de bin-directory.
Selecteer "Niet samenvoegen." Maak aparte assemblies voor elke pagina en controle", en het resultaat is veel meer App_Web_*.dll bestanden in bin.
Op het moment van release genereert de projectroot een PrecompiledApp.config-bestand. De inhoud is als volgt:
Het PrecompiledApp.config-bestand wordt gebruikt om bij te houden hoe de applicatie wordt ingezet en of ASP.NET op het moment van aanvraag bestanden moet compileren op het moment van aanvraag. |
Geplaatst op 22-8-2020 10:05:17
|
|
|
|
