Ja projektā ir pārāk daudz lappušu, IIS tiek startēta un tīmekļa vietne ir ļoti lēna, kad to atverat pirmo reizi, jo projekts nav iepriekš kompilēts izlaišanas brīdī, bet tiek dinamiski kompilēts, kad lietotājs apmeklē tīmekļa lapu. Ja vēlaties uzlabot esošās vietnes veiktspēju un veikt kļūdu pārbaudi savā vietnē, publicējot projektu, ir jāizvēlas "Iepriekš kompilēt izlaišanas laikā".
Ievads
Maziem projektiem publicēšana saskaņā ar noklusējuma iestatījumiem būtībā var izpildīt normālu darbību, pirmā lapa tiek atvērta 56 sekundēs (atkarībā no servera konfigurācijas), un citu lapu pirmā atvēršana būtībā tiek pabeigta 12 sekundēs, nevis pirmā tūlītēja atvēršana.
Kad projekta funkcijas kļūst sarežģītas un failu skaits palielinās, būs nepieciešamas vairāk nekā 30 sekundes, lai atvērtu pirmo lapu pēc publicēšanas, un apmēram 10 sekundes citu lapu pirmajai atvēršanai, nevis pirmajai tūlītējai atvēršanai.
Tas ir tāpēc, ka projekts nav iepriekš kompilēts izlaišanas brīdī, bet tiek dinamiski kompilēts, kad lietotājs piekļūst tīmekļa lapai, un, tiklīdz lietojumprogrammu pūls ir pārstrādāts vai projekta faili ir mainīti, tas tiks pārkompilēts un atkal iziet lēnu "pirmo reizi", kas ir neciešami.
Iepriekšējas kompilācijas priekšrocības
- Veiktspēja. Kompilētais kods tiek izpildīts daudz ātrāk nekā skriptēšanas valodas, piemēram, ECMAScript vai VBScript, jo tas ir attēlojums, kas ir tuvāks mašīnkodam un neprasa papildu analīzi.
- Drošība. Kompilēto kodu ir grūtāk pārveidot nekā nekompilētu avota kodu, jo tam trūkst lasāmības un abstrakcijas, kāda ir augsta līmeņa valodām. Turklāt fuzzing rīki uzlabo kompilētā koda spēju pretoties reversās inženierijas apstrādei.
- Stabilitāte. Kompilācijas laikā pārbaudiet, vai kodā nav sintakses kļūdu, tipa drošības problēmu un citu problēmu. Noķerot šīs kļūdas būvēšanas laikā, kodā var novērst daudzas kļūdas.
- Savietojamība. Tā kā MSIL kods atbalsta jebkuru .NET valodu, kodā ir iespējams izmantot montāžas, kas sākotnēji rakstītas citās valodās. Piemēram, ja rakstāt ASP.NET tīmekļa lapu C#, varat pievienot atsauci uz .dll failu, kas rakstīts programmā Visual Basic.
ASP.NET Core iepriekš kompilēts
Iepriekš sastādīts
Iepriekšēja kompilācija ir ASP .Net Core noklusējuma veids. Publicēšanas laikā visi Razor skati sistēmā pēc noklusējuma ir iepriekš kompilēti. Kompilētā skata DLL tiek vienādi nosaukts xxx.PrecompiledViews.dll vai xxx.Views.dll
Dinamiska kompilācija
Visu projektu ir viegli konfigurēt dinamiskai kompilācijai, vienkārši pievienojiet konfigurācijas projektu MvcRazorCompileOnPublish ar vērtību false
ASP.NET Tīmekļa vietnes iepriekšēja sastādīšana
Mēs izmantojam Visual Studio, lai publicētu tīmekļa vietni šādos veidos:
Opcijas "Atļaut atjauninājumus šai iepriekš kompilētai vietnei" nozīme Kad mēs publicējam .Net tīmekļa projektu, kopumā visi . CS failu, kas automātiski ģenerēs DLL dinamisko saišu bibliotēku, kas var ļoti labi aizsargāt vietnes avota kodu, jo servera puses kods parasti tiek ievietots . Tā kā visi DLL faili CS failā tiek ģenerēti, pēc tam augšupielādējiet tos serverī, citi tos nevar viegli atvērt!
Tomēr citi faili, piemēram, ashx, aspx un citi faili, kas tajā ir, ir tas, kas tas ir, citi var atvērt šos failus, lai tos apskatītu, lai gan citi nevar redzēt CS kodu, bet joprojām var redzēt HTML kodu vai dažas servera vadīklas un saistītos atribūtus ASPX failā; Tāds fails kā ashx ir līdzvērtīgs CS failam, un tajā esošais kods ir viegli saskatāms;
Tāpēc . CS faili ir droši, bet ASPX, ashx un citi faili nav droši; Tātad, vai ir veids, kā padarīt serverī augšupielādētos tīmekļa failus drošus? Ir veids, kā publicēt, neatzīmējiet "Atļaut atjauninājumus šai iepriekš kompilētajai vietnei";
Atzīmējiet opciju Atļaut šīs iepriekš kompilētās vietnes atjauninājumus
Ja, publicējot tīmekli, atzīmējat "Atļaut atjaunināt šo iepriekš kompilēto vietni", rezultāts ir šāds: Viss vietnes fails, izņemot visus CS failus, kas apkopoti DLL failos, citos failos, un oriģinālajam nav izmaiņu, kas ir iekšā vai kas, kamēr citi to atver, izmantojot Notepad, kodu, HTML kodu utt.
Turklāt, kad lietotāji pirmo reizi apmeklē noteiktu lapu, tie ir jāapkopo, lai atrastu kļūdas, un tad, ja nav kļūdu, tiem var piekļūt normāli, tāpēc ātrums kļūs salīdzinoši lēns. Apmeklējumi pēc tam ir normāli;
Noņemiet atzīmi no opcijas "Atļaut šīs iepriekš kompilētās vietnes atjauninājumus"
Ja, publicējot tīmekli, neatzīmējat "Atļaut atjaunināt šo iepriekš kompilēto vietni", rezultāts ir šāds: 1. Visi CS faili vietnē tiek apkopoti DLL failos; 2. Papildus cs failam tiek apkopoti arī citi faili, piemēram, ASPX, ASHX un citi faili, un katrs fails BIN direktorijā ģenerē atbilstošu *.compiled failu;
Pēc tam, ja jūs skatāt ASPX, ASHX un citus failus, izmantojot piezīmju bloku, tajos neredzēsiet nekādu kodu, pat HTML koda marķējums nav redzams, atveriet šādu failu, tajā ir tikai viena teksta rindiņa, saturs ir "Šis ir iezīmēšanas fails, ko ģenerējis iepriekš kompilētais rīks, to nevajadzētu izdzēst!", un šo failu lielums ir 1kb;
Ja jūs mēģināt atvērt mājas lapas lapu, jūs atradīsiet, ka, izņemot pirmo lapu pēc projekta sākuma, kas joprojām aizņem 1 ~ 2 sekundes (bez EF), katra otra lapa pirmo reizi tiek atvērta uzreiz (EF pirmais lēnums ir ārpus šī raksta tvēruma). Tas man liek justies, ka esmu novēlots, lai redzētu iepriekš sastādītu!
Šeit es slepeni saku, ka skati direktorija dzēšana neietekmēs normālu tīmekļa lapas atvēršanu ~ Kāpēc jūs neļaujat to izdzēst, mēs neuzdrošināmies jautāt un mēs neuzdrošināmies to izdzēst.
Mērķis tika sasniegts, un bija dažas sekas, kas bija jāatrisina, piemēram, juceklis tvertņu direktorijā.
Atlasiet "Neapvienot". Izveidojiet atsevišķus komplektus katrai lapai un vadīklai", un rezultāts ir daudz vairāk App_Web_*.dll failu tvertnē.
Izlaišanas brīdī projekta sakne ģenerē failu PrecompiledApp.config. Saturs ir šāds:
Fails PrecompiledApp.config tiek izmantots, lai izsekotu, kā lietojumprogramma tiek izvietota un vai ASP.NET ir jākompilē faili pieprasījuma laikā. |
Publicēts 2020-8-22 10:05:17
|
|
|
|
