Kun projektissa on liikaa sivuja, IIS käynnistyy ja verkkosivusto on hyvin hidas, kun avaat sen ensimmäistä kertaa, koska projekti ei ole valmiiksi käännetty julkaisun aikaan, vaan käännetään dynaamisesti, kun käyttäjä vierailee sivulla. Jos haluat parantaa nykyisen sivustosi suorituskykyä ja tehdä virheentarkistuksen, sinun on valittava "Precompile during release" kun julkaiset projektisi.
Johdanto
Pienissä projekteissa oletusasetuksilla julkaiseminen voi käytännössä täyttää normaalin toiminnan, ensimmäinen sivu avautuu 56 sekunnissa (palvelinkokoonpanosta riippuen), ja muiden sivujen ensimmäinen avaaminen valmistuu käytännössä 12 sekunnissa, ei ensimmäisessä välittömässä avauksessa.
Kun projektin toiminnot monimutkaistuvat ja tiedostojen määrä kasvaa, ensimmäisen sivun avaaminen julkaisun jälkeen kestää yli 30 sekuntia ja noin 10 sekuntia muiden sivujen avaamiseen, ei ensimmäiseen välittömään avaukseen.
Tämä johtuu siitä, että projekti ei ole valmiiksi käännetty julkaisuhetkellä, vaan käännetään dynaamisesti, kun käyttäjä pääsee verkkosivulle, ja kun sovelluspooli on kierrätetty tai projektitiedostot muutetaan, se käännetään uudelleen ja käy läpi hitaasti "ensimmäisen kerran" uudelleen, mikä on sietämätöntä.
Esikokoamisen hyödyt
- Suorituskyky. Käännetty koodi suoritetaan paljon nopeammin kuin skriptikielet kuten ECMAScript tai VBScript, koska se on lähempänä konekoodia eikä vaadi lisäanalyysiä.
- Turvallisuus. Käännetyn koodin käänteissuunnittelu on vaikeampaa kuin kääntämätöntä lähdekoodia, koska siitä puuttuu luettavuus ja abstraktio, joita korkean tason kielillä on. Lisäksi fuzzing-työkalut parantavat käännetyn koodin kykyä vastustaa käänteistä suunnittelua.
- Vakaus. Tarkista koodisi syntaksivirheiden, tyyppiturvallisuusongelmien ja muiden ongelmien varalta käännösvaiheessa. Havaitsemalla nämä virheet rakennusvaiheessa monet virheet voidaan poistaa koodista.
- Yhteentoimivuus. Koska MSIL-koodi tukee mitä tahansa .NET-kieltä, on mahdollista käyttää koodissa alun perin muilla kielillä kirjoitettuja assemblereita. Esimerkiksi, jos kirjoitat ASP.NET verkkosivua C#:lla, voit lisätä viitteen .dll-tiedostoon, joka on kirjoitettu Visual Basicilla.
ASP.NET Ydin esikäännetty
Valmiiksi käännetty
Esikääntäminen on oletustapa ASP .Net Corelle. Julkaisuhetkellä kaikki järjestelmän Razor-näkymät ovat oletuksena valmiiksi käännettyjä. Käännetyn näkymän DLL nimetään yhtenäisesti xxx.PrecompiledViews.dll tai xxx.Views.dll
Dynaaminen kokoelma
Koko projektin konfigurointi dynaamiseksi kääntämiseksi on helppoa, lisää vain konfiguraatioprojekti MvcRazorCompileOnPublish arvolla false
ASP.NET Verkkosivuston esikokoaminen
Käytämme Visual Studiota verkkosivuston julkaisemiseen seuraavilla tavoilla:
"Salli päivitykset tälle esikäännetylle sivustolle" -vaihtoehdon merkitys Kun julkaisemme .Net-verkkoprojektin, yleisesti ottaen kaikki . CS-tiedosto, joka automaattisesti luo DLL-dynaamisen linkkikirjaston, joka suojaa verkkosivuston lähdekoodia erittäin hyvin, koska palvelinpuolen koodi sijoitetaan yleensä . Koska CS-tiedoston DLL-tiedostot on kaikki luotu ja ladataan palvelimelle, muut eivät voi helposti avata niitä!
Kuitenkin muut tiedostot, kuten ashx, aspx ja muut tiedostot, mitä niissä on, on mitä se on, toiset voivat avata nämä tiedostot nähdäkseen, vaikka toiset eivät näe CS-koodia, mutta voivat silti nähdä HTML-koodin tai joitakin palvelinkontrollit ja niihin liittyvät attribuutit ASPX-tiedostossa; Tiedosto kuten ashx vastaa CS-tiedostoa, ja sen koodi on helposti nähtävissä;
Siksi, . CS-tiedostot ovat turvallisia, mutta ASPX, ashx ja muut tiedostot eivät ole turvallisia; Joten, onko olemassa keinoa tehdä palvelimelle ladatuista verkkotiedostoista turvallisia? On olemassa tapa, eli julkaisun yhteydessä ei valita "Salli päivitykset tälle esikäännetylle sivustolle";
Tarkista Salli päivitykset tähän valmiiksi käännettyyn sivustoon
Jos rastitat "Salli päivittää tämä esikäännetty sivusto" verkkoa julkaistessasi, tulos on tämä: Koko verkkosivustotiedosto, paitsi kaikki CS-tiedostot, jotka on käännetty DLL-tiedostoiksi, muiksi tiedostoiksi ja alkuperäiseen, ei muutu, sisällön sisältö tai mitä, kunhan muut avaavat sen Notepadin kautta, koodi, HTML-koodi jne. näkyvät yhdellä silmäyksellä.
Lisäksi, kun käyttäjät vierailevat tietyllä sivulla ensimmäistä kertaa, ne täytyy kääntää virheiden löytämiseksi, ja jos virheitä ei ole, ne voidaan käyttää normaalisti, joten nopeus hidastuu melko paljon. Vierailut sen jälkeen ovat normaaleja;
Poista valinta "Salli päivitykset tälle esikäännetylle sivustolle"
Jos et valitse "Salli päivittää tämä esikäännetty sivusto" verkkoa julkaistessasi, tulos on seuraava: 1. Kaikki sivuston CS-tiedostot käännetään DLL-tiedostoiksi; 2. CS-tiedoston lisäksi myös muita tiedostoja, kuten ASPX, ASHX ja muita tiedostoja, käännetään yhteen, ja jokainen tiedosto tuottaa vastaavan *.compiled-tiedoston BIN-hakemistoon;
Tämän jälkeen, jos katsot ASPX:ää, ASHX:ää ja muita tiedostoja muistion läpi, et näe niissä koodia, edes HTML-koodimerkintä ei näy, avaa tällainen tiedosto, siinä on vain yksi tekstirivi, sisältö on "Tämä on esikäännetyn työkalun tuottama merkintätiedosto, sitä ei pitäisi poistaa!", ja näiden tiedostojen koko on 1kb;
Jos yrität avata verkkosivun sivun, huomaat, että lukuun ottamatta ensimmäistä sivua projektin alkamisen jälkeen, joka vie edelleen 1~2 sekuntia (ei EK:ää), molemmat sivut avautuvat välittömästi (EF:n ensimmäinen hitaus on tämän artikkelin ulkopuolella). Tämä saa minut tuntemaan, että olen myöhässä valmiiksi käännettyjen näkemyksistä!
Tässä salaa sanon, että Näkymähakemiston poistaminen ei vaikuta verkkosivun normaaliin avaamiseen~ Miksi et anna sen poistaa, emme uskalla kysyä, emmekä uskalla poistaa sitä.
Tavoite saavutettiin, ja oli joitakin jälkivaikutuksia, jotka piti ratkaista, kuten bin-hakemiston sotku.
Valitse "Älä yhdistä". Luo erilliset kokoonpanot jokaiselle sivulle ja ohjaukselle", jolloin tuloksena on paljon enemmän App_Web_*.dll tiedostoja binissä.
Julkaisuhetkellä projektin root generoi PrecompiledApp.config-tiedoston. Sisältö on seuraava:
PrecompiledApp.config-tiedostoa käytetään seuraamaan, miten sovellus otetaan käyttöön ja tarvitseeko ASP.NET kääntää tiedostoja pyynnön yhteydessä. |