ASP.NET Web API er en flott teknologi. Å skrive web-API-er er så enkelt at mange utviklere ikke bruker tid på å strukturere applikasjonene sine for å oppnå god kjøringsytelse.
I denne artikkelen vil jeg dekke 8 teknikker for å forbedre ytelsen til ASP.NET web-API-er.
1) Bruk det raskeste JSON-serialiseringsverktøyet
Serialiseringen av JSON har en kritisk innvirkning på ytelsen til hele ASP.NET Web API. I et av prosjektene mine byttet jeg fra JSON.NET serializer til ServiceStack.Text i halvannet år.
Jeg har målt at ytelsen til Web API-et har forbedret seg med omtrent 20 %. Jeg anbefaler sterkt at du prøver dette serialiseringsverktøyet. Her er noen nylige sammenligningsdata om ytelsen til populære serialiseringsverktøy.
SerializerPerformanceGraf
Kilde: theburningmonk
Oppdatering: Det ser ut til at StackOverflow bruker Jil, deres påståtte JSON-serialiseringsverktøy til dags dato. Testdata finnes på deres GitHub-side Jil serializer.
2) Manuelt serialisere JSON fra DataReader
Jeg har brukt denne tilnærmingen i prosjektene mine og har fått ytelsesfordeler.
Du kan manuelt lage JSON-strenger fra DataReader og unngå unødvendig objektopprettelse, slik at du ikke trenger å ta verdier fra DataReader og skrive til objekter, deretter ta verdier fra disse objektene og bruke JSON Serializer for å generere JSON.
Bruk StringBuilder for å generere JSON og returner StringContent til slutt som innholdet i svaret i WebAPI-en.
Du kan se flere måter å gjøre dette på på Rick Strahls blogg
3) Bruk andre protokollformater (protokollbuffer, meldingspakke) så mye som mulig
Hvis du kan bruke andre meldingsformater i prosjektet ditt, som Protocol Buffers eller MessagePacks, i stedet for å bruke JSON.
Du får en stor ytelsesfordel, ikke bare fordi protokollbuffere er veldig raske i serialisering, men også fordi de formateres raskere enn JSON i de returnerte resultatene.
4) Implementer komprimering
Bruk GZIP eller Deflate i ditt ASP.NET Web API.
Komprimering er en enkel og effektiv måte å redusere størrelsen og responsiviteten til responspakker på.
Dette er en veldig nødvendig funksjon, du kan lese flere artikler om komprimering på bloggen min ASP.NET Web API GZip compression ActionFilter med 8 linjer kode.
5) Bruk caching
Å bruke output caching i Web API-metoden er dyptgripende. For eksempel, hvis et stort antall brukere får tilgang til responsinnhold som bare endres én gang om dagen.
Hvis du vil implementere manuell caching, som å cache brukerpassord til minnet, se blogginnlegget mitt Enkel måte å implementere caching på i ASP.NET Web API.
6) Bruk typisk ADO.NET når det er mulig
Manuelt skrevet ADO.NET er fortsatt den raskeste måten å hente verdier fra databasen på. Hvis ytelsen til web-API-ene dine er veldig viktig for deg, bør du ikke bruke ORM-er.
Du kan se ytelsessammenligninger mellom de mest populære ORM-ene.
ORMMapper
Dapper og håndskrevet hentekode er raske, og ganske riktig, alle ORM-er er tregere enn de tre.
LLBLGen med en resultset-cache er raskt, men den må re-iterere resultsset og instansiere objektet i minnet igjen.
7) Implementer en asynkron tilnærming i Web API-et
Bruk av en asynkron Web API-tjeneste øker dramatisk antallet HTTP-forespørsler som web-API-er behandler.
Implementeringen er enkel, bare bruk det asynkrone nøkkelordet og endre returverditypen for metoden din til Oppgave.
8) Returnerer flere resultatsett og kombinasjoner av sett
Å redusere antall overføringer er ikke bare gunstig for flere databaser, men også for web-API-er, som lar deg bruke kraften i resultatsett.
Dette betyr at du kan hente ut flere resultatsett fra DataReader, se følgende demokode:
Du kan returnere flere objekter i ett svar fra et Web-API, prøv å kombinere de returnerte objektene dine og returner følgende objekter:
Dette vil redusere HTTP-forespørsler til ditt WEB API.
Takk for at du leste denne artikkelen.
|
Publisert på 11.01.2016 14:37:43
|
|
|
|
