Optimizarea aplicațiilor, setarea mediului

În plus față de codul nostru, fiecare cererile de intrare și de ieșire sunt manipulate răspunsurile componente ASP.NET. Unele mecanisme ale unei ASP.NET, cum ar fi Viewstate, au fost furnizate pentru nevoile de dezvoltare, dar ele pot afecta performanța generală a aplicației. Atunci când reglaj fin aplicația ASP.NET, se recomandă să se schimbe comportamentul implicit al unora dintre aceste mecanisme, deși, uneori, aceste modificări pot necesita modificări ale codului aplicației.







Dezactivarea mecanismelor de urmărire și depanare în ASP.NET

Motorul de urmărire ASP.NET permite dezvoltatorilor să obțină informații de diagnosticare pentru o anumită pagină, de exemplu timpul de rulare și calea sa, starea sesiunii și o listă cu anteturile HTTP.

Deși mecanismul de urmărire vă permite să obțineți informații neprețuite în timpul dezvoltării și depanării aplicațiilor ASP.NET, are un impact negativ asupra performanței generale a aplicației, colectând informații despre fiecare solicitare. Asta este, dacă suportul de urmărire a fost activat în timpul fazei de dezvoltare, dezactivați-l înainte de implementarea aplicației în mediul de producție, pur și simplu schimbând parametrul de urmărire în fișierul web.config:

În mod implicit, dacă nu este specificat altfel, trasarea este dezactivată (enabled = "false"), astfel încât să puteți dezactiva urmărirea prin simpla ștergere a parametrului de urmărire din fișierul web.config.

Când se creează o nouă aplicație web bazată pe ASP.NET, secțiunea system.web -> compilație de configurare este adăugată automat la fișierul web.config cu atributul de depanare setat la true:

Problema cu această opțiune este că dezvoltatorii de multe ori uitați să-l setat la fals atunci când sunt instalate pe serverul web existent, sau un concediu special în sensul adevărat, pentru a putea obține mai multe informații în caz de excepții. Acest lucru poate duce la mai multe probleme legate de performanță:

Scripturile descărcate utilizând funcția Handler WebResources.axd. De exemplu, atunci când paginile utilizează verificări de validare, acestea nu vor fi stocate în cache de către browser. Când flagul de depanare este setat la false, răspunsurile de la acest handler vor fi furnizate cu anteturi care permit cache, permițând browserelor să stocheze rezultatele în memoria cache pentru utilizare ulterioară.

Când parametrul de depanare este setat la false, timpul de procesare a interogării nu este setat. Deși este foarte util în depanare, un astfel de comportament nu este de dorit într-un mediu industrial, deoarece astfel de solicitări pot conduce la faptul că serverul nu este în măsură să serviciu alte cereri, sau chiar cauza o sarcină excesivă asupra procesorului, consumul a crescut de memorie și pot cauza alte probleme cu alocarea resurselor.

Setarea semnalizatorului de depanare la fals va permite runtime-ului ASP.NET să definească timeouts pentru procesarea cererilor în funcție de setările httpRuntimeExecutionTimeout (valoarea implicită este de 110 secunde).

Când debug este adevărat, compilatorul JIT nu va optimiza codul. Aceste optimizări sunt unul dintre cele mai importante avantaje ale mediului .NET și pot oferi o creștere semnificativă a performanței aplicației ASP.NET fără a schimba codul. Setarea depanării la fals va permite compilatorului JIT să-și facă treaba și să facă aplicația mai rapidă și mai eficientă.

Pentru a schimba acest parametru este foarte simplu: ștergeți complet atributul de depanare din fișierul de configurare complet sau îl setați la fals:

Dacă te temi că vei uita să modificați această setare atunci când aplicația este implementată pe serverul existent, puteți face toate aplicațiile ASP.NET ignora opțiunea de depanare de pe server, următorul cod în fișierul Machine.config pe server:







Dezactivarea funcției ViewState

Mecanismul de persistență a vizualizării ViewState este utilizat în aplicațiile Web Forms ASP.NET pentru a stoca starea paginii în marcajul HTML afișat (aplicațiile MVC ASP.NET nu utilizează acest mecanism). Motorul ViewState permite ASP.NET să salveze starea paginii pentru ao trimite din nou de către utilizator. Datele sunt salvate în format HTML, criptate (în mod implicit, criptarea este dezactivată), codificată într-un șir Base64 și stocată într-un câmp ascuns. Când utilizatorul trimite pagina înapoi, conținutul câmpului este decodificat și transformat înapoi în matricea asociativă. Multe instrumente de administrare a serverului utilizează mecanismul ViewState pentru a-și păstra propriile informații, de exemplu, valori ale proprietăților lor.

Creșterea numărului de pagini la utilizarea mecanismului ViewState trece de obicei neobservată pentru clienții care accesează serverul web din rețeaua locală. Acest lucru se datorează faptului că rețelele locale au de obicei o rată de transfer ridicată, iar transportul paginilor foarte mari în astfel de rețele este de milisecunde (într-o rețea Gigabit optimizată, lățimea de bandă poate ajunge

40-100 MB / s, în funcție de hardware-ul folosit). Cu toate acestea, în rețelele globale mai lente, cum ar fi Internetul, creșterea dimensiunilor paginilor devine mai vizibilă.

Dacă aplicația nu are nevoie să utilizeze acest mecanism, este mai bine să o dezactivați. Puteți dezactiva motorul ViewState în fișierul web.config, pentru întreaga aplicație:

Dacă nu poate fi dezactivată pentru întreaga aplicație, puteți preveni utilizarea ViewState pe o pagină separată și toate comenzile acesteia:

De asemenea, este posibil să dezactivați suportul ViewState în controale separate:

Înainte de ASP.NET 4, dezactivarea suportului ViewState în pagină a făcut imposibilă includerea acestuia în controale separate pe pagină. Începând cu versiunea ASP.NET 4, această caracteristică a fost adăugată. Acest lucru este realizat utilizând proprietatea ViewStateMode. De exemplu, următorul cod dezactivează suportul ViewState pentru întreaga pagină, cu excepția controlului ListView:

Setarea atributului EnableViewState la falsă are o prioritate mai mare decât atributele ViewStateMode. Asta este, dacă intenționați să utilizați atributele ViewStateMode, asigurați-vă că setați atributul EnableViewState la adevărat sau doar ștergeți (este implicit la adevărat).

Cache de ieșire din partea serverului

Paginile ASP.NET sunt considerate dinamice, în sensul conținutului, cu toate acestea, adesea un astfel de conținut dinamic al paginilor nu se schimbă odată cu timpul. De exemplu, o pagină poate accepta un ID de produs și poate întoarce marcajul HTML cu descrierea sa. Pagina însăși este dinamică, deoarece poate returna o descriere diferită pentru diferite produse, dar descrierea unui anumit produs nu se modifică, cel puțin până când se schimbă în baza de date.

Continuând exemplul cu produsul pentru a preveni executarea cererilor repetate la baza de date de fiecare dată când un utilizator solicită o descriere a produsului, puteți salva descrierea din memoria cache locală și să ofere mai rapid de recuperare a acestuia, dar încă mai trebuie să genereze HTML marcare ca răspuns la fiecare cerere . În schimb, cache-ul de date sursă, ASP.NET oferă o altă oportunitate - ASP.NET Cache mecanism de ieșire. unde se păstrează marcajul HTML în sine.

Datorită acestui mecanism, devine posibilă stocarea marcajului HTML, care va reveni automat ca răspuns la solicitările ulterioare, ocolind stadiul de executare a codului care generează pagina. Cache-ul de ieșire din ASP.NET este, de asemenea, acceptat pentru aplicațiile bazate pe Formulare Web, în ​​care paginile sunt stocate în memoria cache și pentru aplicațiile bazate pe ASP.NET MVC unde sunt stocate rezultatele operațiilor controlerului.

De exemplu, codul următor utilizează cache-ul de ieșire pentru a stoca vizualizarea returnată de operatorul MVC ASP.NET pentru o perioadă de până la 30 de secunde:

Dacă operația de index din exemplul de mai sus a avut un parametru cu identificatorul de produs și a returnat o vizualizare cu informații despre un anumit produs, am avea nevoie să stocăm în cache mai multe versiuni ale ieșirii pentru identificatori diferiți. Prin urmare, cache-ul de ieșire acceptă nu numai capacitatea de a salva o singură versiune a datelor de ieșire, ci și diferite versiuni ale datelor generate de aceeași operație, cauzate de diferiți parametri.

În plus față de parametrii de interogare, mecanismul de memorare în cache de ieșire poate lua în considerare și antetele de cerere HTTP, cum ar fi Accept-Encoding și Accept-Language. De exemplu, dacă metoda de controler poate returna conținut în diferite limbi, în funcție de antetul Accept-Language HTTP, puteți configura contul pentru acest antet și puteți stoca diferite versiuni ale ieșirii în limbi diferite în memoria cache.

Dacă aceleași setări hash sunt aplicate diferitelor pagini sau operații, puteți crea un profil cache și îl puteți utiliza, în loc să repetați setările din nou și din nou. Profilurile caching sunt create în fișierul web.config, în secțiunea system.web -> cache. De exemplu, fragmentul următor declară un profil de cache care este destinat a fi utilizat cu pagini diferite:

Acum puteți aplica acest profil la operația Index:







Articole similare

Trimiteți-le prietenilor: