Caching er en statsadministrasjonsstrategi som ofte blir vedtatt i ASP.Net for å forbedre applikasjonens ytelse ved å minimere ressursforbruket i systemet ditt. Hvis det brukes riktig, kan det forbedre ytelsen til applikasjonen din betydelig ved å lagre wWb-siden helt eller delvis, eller til og med lagre programmets data på tvers av HTTP-forespørslene. Caching gjør at websiden kan gjengis raskere, og riktig bruk av caching minimerer eller reduserer databasetreff eller forbruk av serverens ressurser.
Caching i ASP.Net er av følgende tre typer:
- hurtigbufring av side
- sidefragmentbufring
- data caching
Sideleiebufring
Dette er en form for hurtigbufring i ASP.Net som lagrer en kopi av websiden din i minnebufferen, slik at etterfølgende forespørsler om den samme websiden kan hentes direkte fra hurtigbufferen - den bufrede utgangen sendes til applikasjonen. Dette forbedrer applikasjonens ytelse betraktelig. Følgende kodebit viser hvordan du kan implementere hurtigbufring av side.
Alternativet VaryByParam hjelper deg med å spesifisere variablene i Http-forespørsel som trenger en ny cacheoppføring. Andre mulige alternativer inkluderer: VaryByHeader og VaryByCustom. Du kan også spesifisere plassering og varighet i OutputCache-direktivet - du kan bruke disse til å spesifisere plasseringen til hurtigbufferen og også hvor lenge websiden skal caches.
Sidefragmentbufring
Sidefragmentbufring er en hurtigbufringstrategi der websiden delvis caches - bare fragmenter av websiden er bufret, ikke hele websiden. Du kan bruke den samme syntaksen som hurtigbufring av side. Du må imidlertid bruke OutputCache-attributtet på en brukerkontroll i stedet for websiden. Fragmentbuffering er nyttig når du bare trenger å cache deler av websiden din - vanligvis i situasjoner der websiden inneholder en blanding av vanlige og dynamiske seksjoner. Som et eksempel kan du ha en webside som inneholder en blanding av menyelementer og også visse dynamiske seksjoner som ofte må fylles ut og oppdateres fra databasen.
Datacaching
ASP.Net avslører Cache API for deg å lagre data i cachen for henting senere. Syntaksen for lagring av data i hurtigbufferen ved hjelp av hurtigbuffer-API er gitt nedenfor.
Cache ["key"] = "verdi";
Du kan også bruke metodene Legg til eller Sett inn. For å fjerne en oppføring fra hurtigbufferen, kan du bruke Fjern () -metoden i Cache-klassen. Metoden Insert () i Cache-klassen lar deg spesifisere cache-avhengighet. Cache-avhengighet er en strategi som sikrer at når dataene i datalageret (som hurtigbufferen er fylt ut fra) endres, vil hurtigbufferen deretter bli fylt ut umiddelbart. Når data i datalageret endres, vil hurtigbufferen utløpe, noe som resulterer i en hurtigutfylling av hurtigbufferen med de siste dataene. Du kan lese mer om dette fra denne MSDN-artikkelen.
Beste praksis
Du bør cache så ofte du kan og cache data riktig i hvert lag i applikasjonen. Når du bruker datacaching, bør du implementere en riktig strategi for å sikre at data i hurtigbufferen er synkronisert med det i datalageret. Du kan dra nytte av distribuerte cache-administratorer som Memcached, slik at cachestrategien din også kan skaleres godt og gi betydelige ytelsesgevinster - du kan bruke Memcached til å lagre store data. Du bør sørge for at du bare cache relativt foreldede data - det er ikke noe poeng i å cache data som vil endres ofte over tid. Også data som neppe vil bli gjenbrukt, bør ikke lagres i hurtigbufferen. Du bør ikke bruke SqlDependency eller SqlCacheDependency for mye.
Og nå, la oss kjenne til ulempene med hurtigbufring også. Cache-objektet er bare tilgjengelig for det nåværende applikasjonsdomenet. Så hvis du ønsker å lagre data i hurtigbufferen og gjøre den tilgjengelig på tvers av en nettgård, er det ikke en mulighet. Du må utnytte distribuert cache som Windows Server AppFabric Caching eller andre distribuerte caching-rammer for å ha dataene i cachen globalt tilgjengelig i en nettgård.
Caching er en kraftig mekanisme for å øke applikasjonens ytelse ved å lagre relativt foreldede data i minnet slik at det samme kan hentes fra hurtigminnet på et senere tidspunkt. Jeg vil diskutere mer om dette emnet med eksempler på virkelige livskoder i mine fremtidige innlegg her.
