Introduksjon til hurtigbufring i ASP.NET
Cache i ASP.NET er muligheten til å lagre en webside eller data i minnet for rask tilgang. I ASP.NET trenger du ikke treffe serveren for samme respons igjen og igjen. Lagre det i datamaskinens minne og hent det raskere. Selvfølgelig fungerer dette bare med statiske data fordi dynamiske data varierer med hver forespørsel som sendes til serveren.
Hva er hurtigbuffer i ASP.Net?
.Net-rammeverket gir også hurtigbufferanlegget slik at ytelsen til applikasjonen din kan forbedres. Nå spør du, ASP. Net brukes til å lage brukeravhengige dynamiske websider, hvordan kan det deretter bufres innhold?
La oss forstå dette med to scenarier - først der siden er brukerens instrumentpanel og for det andre der den har produktoppføringer. Scenario to er uavhengig av brukeren, produktene er de samme med hver forespørsel til serveren, og dermed kan hele siden bufres. Igjen er prisen og tilgjengeligheten til produkter varierende, som kan håndteres ved rettidig oppdatering av hurtigbufferen. Scenario en er avhengig av brukeren. Dashbordet for en bruker er kanskje ikke likt en annen bruker i det hele tatt. Men det er fremdeles noen få komponenter som bilder, legender, topptekster og bunntekst som kan bufres for å forbedre ytelsen. ASP.Net gjør det mulig for utviklerne å håndtere begge slags scenarier effektivt i applikasjonen sin.
Hvordan fungerer cache i ASP.Net?
Det er veldig viktig å forstå prosessen med ASP.Net bufrer websider eller data. For å forstå dette, må vi forstå .Net-samlingsprosessen, slik at vi får en rettferdig forståelse av når og hvor vi kan cache sidene for optimal ytelse. ASP.Net sidekode er satt sammen i to trinn MSIL-trinnet og JIT-trinnet. I MSIL-trinnet er sidekoden skrevet på høyt nivå-språk kompilert til Microsoft Intermediate Language. Dette skjer når vi bygger prosjektet vårt. Hele nettstedet eller prosjektet er samlet i MSIL hver gang vi bygger. I JIT-trinnet blir MSIL-koden deretter konvertert til egen maskinkode av Just In Time-kompilatoren. Dette skjer under utførelsen av siden. Imidlertid konverteres ikke hele prosjektet til native code hele tiden. Bare sidene som brukeren etterspør, blir konvertert fra MSIL til native code under utførelsen. Dette sparer mye nettverksbåndbredde og forbedrer ytelsen.
Nå, hvilken kode skal vi cache, når skal vi cache og hvor?
ASP.Net har en fullfunksjonsmotor dedikert til hurtigbufring. Den har funksjoner som tidsavhengighet, fil- og nøkkelavhengighet, utløp, datafanging, etc. Vi vil ikke gå inn på disse detaljene i denne artikkelen. Det vi trenger å forstå er at vi kan bufret sidene og dataene våre på to steder for å forbedre ytelsen til ASP.Net-applikasjonen. Den første plasseringen er delen Page Cache som ligger på ASP.Net-serveren. Denne lagrer sideutgangsbuffer og hurtigbuffer for sider, i utgangspunktet ASPX-sider. Hver gang en for det meste statisk side blir bedt om, lagres en kopi av den genererte innfødte koden i Page Cache-delen. Dette sparer JIT-kompileringstiden under påfølgende sideforespørsler. Den andre plasseringen er Data Cache. Dette lagrer dataene hentet fra dataserverne eller andre servere. Lagring av en kopi av disse dataene hjelper deg med å lagre fremtidige nettverkssamtaler til databaseserverne eller andre tredjepartsservere. Noen få eksempler på hurtigbufrede data er SQL Server-data, XML-data, JSON-data, tredjeparts API-svar, etc.
Typer hurtigbufring i ASP.Net
1. Bufring av sideutgang
Page Output Caching betyr å hurtigbuffe hele utdataet til den forespurte siden. Hver gang en bruker ber om en ASP.Net-side, sammenstiller JIT-kompilatoren den relevante MSIL-koden og genererer den native koden som skal sendes som et svar til klienten. Dette betyr at hver gang siden blir bedt om, må JIT-kompilatoren generere den opprinnelige koden. Hva om siden er statisk? Hva om sideutgangen er den samme etter hver kompilering? Vi kan spare mye tid og ressurser på samlingen hvis vi lagrer den genererte innfødte koden i Page Cache. De påfølgende forespørslene for den samme siden kan hentes fra cachen i stedet. Dette betegnes som sideutgangsbufring. For å oppnå hurtigbufring av sider, må vi spesifisere OuputCache-direktivet i ASP.Net-koden med varighet i sekunder.
2. Bufring av sidefragment
Vi har sett hvordan du hurtigbuffer en statisk side. Hva om siden er dynamisk og varierer med brukerne? Her kommer Page Fragment Caching. Det gjør det mulig for en utvikler å buffer spesifikke deler av siden. Dette hjelper når du vil buffe toppteksten og bunnteksten, som for det meste er statisk for alle brukere. For å oppnå hurtigbufring av sider i ASP.Net, må du innkapsle fragmentkoden i en egen brukerkontroll. Legg deretter til det samme OuputCache-direktivet i brukerkontrollen. Når brukerkontrollen lastes sammen med siden, opprettholdes en kopi av den i hurtigbufferen. Dermed vil alle etterfølgende referanser til den samme brukerkontrollen på den samme siden eller en annen side hentes fra cachen.
3. Data-hurtigbufring
Data Cache er mekanismen for å lagre nødvendige data, som ofte er tilgjengelige, i cache. Dette kan forbedre ytelsen til applikasjonen dramatisk. Dette er fordi datatlagring sparer databasen tur-retur-anrop, som er beryktet for å bruke mest mulig tid. Når ofte tilgjengelige og sjelden endrede data blir bufret, henter serveren dataene fra hurtigbufferen i stedet for å foreta databasesamtaler. Dette kan også spare deg for litt penger når databasesamtaler til nettsky-dataserverne belaster deg per forespørsel. Data Caching i ASP.Net er en fullverdig motor i seg selv. For å oppnå hurtigbufring på ASP-siden vår, må vi bruke Cache-objektet.
Cache("ProductName")="My Product";
Label1.Text= Cache("ProductName").ToString();
Hvorfor trenger vi hurtigbufring i ASP.Net?
Etter å ha forstått hurtigbufringsprosessen i ASP.Net, la oss se på noen praktiske eksempler der hurtigbufring implementeres i sanntidsscenarier.
- Det er en informativ side som genererer rapporter basert på dataene i databasen. Databasetabellene blir oppdatert med få timer.
Page Output Caching kan brukes i et slikt scenario med en varighet på hurtigbufferen som er tilpasset frekvensen for dataoppdateringsjobben. - Det er en side som viser flere tabeller og data som stadig endres. Sagnene og forklaringen på dataene forblir imidlertid de samme.
Sidefragment-hurtigbuffring kan bare brukes til å hurtigbuffe den statiske legenden og forklaringsdata. - Det er et bruker-dashbord som er brukertilpasset og genererer grafer og diagrammer på brukerforespørsler. Dataene som brukes til å generere grafer og diagrammer endres sjelden.
Data-hurtigbuffer kan brukes til å cache dataene og dynamisk generere brukerforespurte diagrammer og grafer.
Konklusjon
Dermed har vi lært at hurtigbufring kommer langt i å forbedre ytelsen til ASP.Net-applikasjonen. Dette var en introduksjonsartikkel om hurtigbufring i ASP.Net. Det er mer å utforske. Det anbefales å lære mer om hurtigbufring for å forbedre applikasjonens ytelse ytterligere.
Anbefalt artikkel
Dette har vært en guide til Caching i ASP.NET. Her diskuterer vi Introduksjon til hurtigbufring i ASP.NET og dets arbeid sammen med typer hurtigbufring. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- ASP.NET Framework
- ASP.Net valideringskontroller
- Karriere i ASP.NET
- .NET intervjuspørsmål