Când sunt prea multe pagini într-un proiect, IIS pornește și site-ul este foarte lent când îl deschizi pentru prima dată, deoarece proiectul nu este precompilat la momentul lansării, ci este compilat dinamic când utilizatorul vizitează pagina web. Dacă doriți să îmbunătățiți performanța site-ului existent și să efectuați verificarea erorilor pe site, este necesar să selectați "Precompilare în timpul lansării" atunci când publicați proiectul.
Introducere
Pentru proiecte mici, publicarea conform setărilor implicite poate funcționa practic normal, prima pagină se deschide în 56 de secunde (în funcție de configurația serverului), iar prima deschidere a celorlalte pagini se finalizează practic în 12 secunde, nu prima deschidere instantanee.
Odată ce funcțiile proiectului devin complexe și numărul de fișiere crește, va dura mai mult de 30 de secunde să se deschidă prima pagină pentru prima rulare după publicare și aproximativ 10 secunde pentru prima deschidere a celorlalte pagini, nu pentru prima deschidere instantanee.
Acest lucru se datorează faptului că proiectul nu este precompilat la momentul lansării, ci este compilat dinamic când utilizatorul accesează pagina web, iar odată ce pool-ul de aplicații este reciclat sau fișierele proiectului sunt modificate, acesta va fi recompilat și va trece din nou printr-o "primă dată" lentă, ceea ce este intolerabil.
Beneficiile precompilației
- Performanță. Codul compilat este executat mult mai rapid decât limbajele de scripting precum ECMAScript sau VBScript, deoarece este o reprezentare mai apropiată de codul mașină și nu necesită analize suplimentare.
- Securitate. Codul compilat este mai greu de realizat invers decât codul sursă necompilat, deoarece îi lipsește lizibilitatea și abstracția pe care le au limbajele de nivel înalt. În plus, uneltele de fuzzing îmbunătățesc capacitatea codului compilat de a rezista procesării de inginerie inversă.
- Stabilitate. Verifică-ți codul pentru erori de sintaxă, probleme de siguranță a tipurilor și alte probleme la compilare. Prin detectarea acestor erori la timpul compilației, multe erori pot fi eliminate în cod.
- Interoperabilitate. Deoarece codul MSIL suportă orice limbaj .NET, este posibil să se folosească asamblări scrise inițial în alte limbaje în cod. De exemplu, dacă scrii ASP.NET pagină web în C#, poți adăuga o referință la un fișier .dll scris în Visual Basic.
ASP.NET Core precompilat
Precompilat
Precompilarea este metoda implicită pentru ASP .Net Core. La momentul publicării, toate vizualizările Razor din sistem sunt precompilate implicit. DLL-ul cu vizualizare compilată poartă denumirea uniformă xxx.PrecompiledViews.dll sau xxx.Views.dll
Compilație dinamică
Este ușor să configurezi întregul proiect pentru compilare dinamică, doar adaugă un proiect de configurare MvcRazorCompileOnPublish cu valoarea false
ASP.NET Pre-compilare a site-ului web
Folosim Visual Studio pentru a publica un site web în următoarele moduri:
Semnificația opțiunii "Permiteți actualizări la acest site precompilat" Când publicăm un proiect web .Net, în general, toate fișierele . CS, care va genera automat o bibliotecă DLL dynamic link, ce poate proteja foarte bine codul sursă al site-ului, deoarece codul de pe serverul este de obicei plasat în . Deoarece fișierele DLL din fișierul CS sunt toate generate, apoi le încarcă pe server, ceilalți nu le pot deschide ușor!
Totuși, alte fișiere, cum ar fi ashx, aspx și alte fișiere, ceea ce conține este ceea ce este, alții pot deschide aceste fișiere pentru a le vizualiza, deși alții nu pot vedea codul CS, dar pot vedea codul HTML sau unele controale de server și atribute conexe în fișierul ASPAC; Un fișier precum ashx este echivalent cu un fișier CS, iar codul din el poate fi ușor de văzut;
Prin urmare, . Fișierele CS sunt sigure, dar fișierele ASPX, ashx și alte fișiere nu sunt sigure; Deci, există vreo modalitate de a face fișierele web încărcate pe server sigure? Există o metodă, adică, la publicare, să nu bifezi "Permite actualizări pentru acest site precompilat";
Verifică actualizările Permite acest site precompilat
Dacă bifezi "Permite actualizarea acestui site precompilat" când publici site-ul, rezultatul este următorul: întregul fișier site, cu excepția tuturor fișierelor CS compilate în fișiere DLL, a altor fișiere și a celui original nu are modificări, ce conține sau ce, atâta timp cât alții îl deschid prin Notepad, codul, codul HTML etc. din interior pot fi văzute de alții dintr-o privire.
În plus, când utilizatorii vizitează pentru prima dată o anumită pagină, acestea trebuie compilate pentru a găsi bug-uri, iar dacă nu există erori, acestea pot fi accesate normal, astfel încât viteza va deveni relativ lentă. Vizitele după aceea sunt normale;
Debifează "Permite actualizări la acest site precompilat"
Dacă nu bifați "Permite actualizarea acestui site precompilat" atunci când publicați site-ul, rezultatul este următorul: 1. Toate fișierele CS din site sunt compilate în fișiere DLL; 2. Pe lângă fișierul cs, alte fișiere, precum ASPX, ASHX și alte fișiere, sunt de asemenea compilate împreună, iar fiecare fișier generează un fișier *.compiled corespunzător în directorul BIN;
După aceea, dacă vizualizezi fișierele ASPX, ASHX și alte fișiere prin caietul, nu vei vedea niciun cod în ele, nici măcar marcajul codului HTML nu este vizibil; deschide un astfel de fișier, conține doar o linie de text, conținutul fiind "Acesta este un fișier de marcaj generat de unealta precompilată, nu trebuie șters!", iar dimensiunea acestor fișiere este de 1kb;
Dacă încerci să deschizi o pagină de site, vei observa că, cu excepția primei pagini după ce proiectul începe, care tot durează 1~2 secunde (fără EF), prima dată când fiecare pagină se deschide instantaneu (prima lentoare a EF depășește scopul acestui articol). Asta mă face să simt că întârzii să văd precompilate!
Aici vă spun în secret că ștergerea directorului Views nu va afecta deschiderea normală a paginii web~ De ce nu lăsați să fie șters, nu îndrăznim să întrebăm și nici nu îndrăznim să ștergem.
Scopul a fost atins, iar unele efecte secundare trebuiau rezolvate, cum ar fi aglomerația din registrul bin (bin directory).
Selectează "Nu fuzionați". Creează asamblări separate pentru fiecare pagină și control", iar rezultatul este mult mai multe fișiere App_Web_*.dll în bin.
La momentul lansării, rădăcina proiectului generează un fișier PrecompiledApp.config. Conținutul este următorul:
Fișierul PrecompiledApp.config este folosit pentru a urmări modul în care aplicația este implementată și dacă ASP.NET trebuie să compileze fișiere la momentul solicitării. |
Postat la 2020-8-22 10:05:17
|
|
|
|
