ASP.NET Web API nagyszerű technológia. Webes API-k írása annyira egyszerű, hogy sok fejlesztő nem tölti az időt az alkalmazásai strukturálásával, hogy jó végrehajtási teljesítményt érjenek el.
Ebben a cikkben 8 technikát fogok bemutatni a ASP.NET webes API-k teljesítményének javítására.
1) Használd a leggyorsabb JSON serializációs eszközt
A JSON serializálása kritikus hatással van az egész ASP.NET Web API teljesítményére. Az egyik projektemben másfél évig átváltottam a JSON.NET serializerről a ServiceStack.Text-re.
Azt mértem, hogy a Web API teljesítménye körülbelül 20%-kal javult. Nagyon ajánlom, hogy próbáld ki ezt a serializációs eszközt. Íme néhány friss összehasonlító adat a népszerű serializációs eszközök teljesítményéről.
SerializerPerformanceGraf
Forrás: theburningmonk
Frissítés: Úgy tűnik, hogy a StackOverflow a Jil-t használja, ami eddig állított JSON serializációs eszközük. A tesztadatok megtalálhatók a GitHub oldalukon, a Jil serializer-en.
2) A JSON manuális serializálása a DataReaderből
Ezt a megközelítést alkalmaztam a projektjeimben, és teljesítménybeli előnyöket kaptam.
Manuálisan létrehozhatsz JSON stringeket a DataReaderből, így elkerülheted a felesleges objektumteremtést, így nem kell értékeket venned a DataReaderből és objektumokhoz írni, majd ezekből az objektumokból értékeket veheted, és a JSON Serializerrel generálni JSON-t.
Használd a StringBuildert a JSON generálásához, és a végén a válasz tartalmának a WebAPI-ban a StringContent visszaállítására.
További módokat is megnézhetsz erre Rick Strahl blogján
3) Használj minél többet más protokollformátumokat (protokollpuffer, üzenetcsomag)
Ha más üzenetformátumokat használhatsz a projektedben, például Protocol Buffers vagy MessagePacks, a JSON helyett.
Óriási teljesítményelőnyt kapsz, nemcsak azért, mert a protokollpufferek nagyon gyorsak a serializációban, hanem azért is, mert a visszaadott eredményekben gyorsabban vannak formázva, mint a JSON.
4) Tömörítés megvalósítása
Használj GZIP-et vagy Deflate-et a ASP.NET Web API-dban.
A tömörítés egyszerű és hatékony módja a válaszcsomagok méretének és reagálási képességének csökkentésének.
Ez egy nagyon szükséges funkció, további cikkeket is megnézhetsz a blogomban a tömörítésről, ASP.NET Web API GZip tömörítésű ActionFilter, 8 sor kóddal.
5) Gyorsítótározás használata
A kimeneti gyorsítótározás használata a Web API módszerben mélyreható. Például, ha nagy számú felhasználó hozzáfér a választartalomhoz, amely naponta egyszer változik.
Ha manuális gyorsítótározást szeretnél megvalósítani, például felhasználói jelszavakat memóriába gyorsítani, lásd a blogbejegyzésemet: Egyszerű módja a gyorsítótározás megvalósításának ASP.NET Web API-ban.
6) Használj a tipikus ADO.NET, amikor csak lehet.
A kézzel írt ADO.NET még mindig a leggyorsabb módja annak, hogy értékeket szerezzünk az adatbázisból. Ha a webes API-k teljesítménye nagyon fontos számodra, akkor ne használj ORM-eket.
A legnépszerűbb ORM-ek teljesítményösszehasonlításait is láthatod.
ORMMapper
A dapper és kézzel írt fetch kód gyors, és valóban, minden ORM lassabb, mint a három.
Az LLBLGen eredményet gyorsítótárral gyors, de újra kell ismételnie az eredményhalatot, és újra meg kell jelenítenie az objektumot a memóriában.
7) Aszinkron megközelítés megvalósítása a Web API-ban
Egy aszinkron Web API szolgáltatás használata jelentősen növeli a webes API-k által feldolgozott HTTP kérések számát.
A megvalósítás egyszerű: csak használd az aszinkron kulcsszót, és változtasd meg a metódusz visszaküldési érték típusát Task-ra.
8) Több eredményhalmazt és halmazkombinációt ad vissza
Az átvitelek számának csökkentése nemcsak több adatbázis számára előnyös, hanem a webes API-k számára is, amelyek lehetővé teszik az eredményhalmazok erejének kihasználását.
Ez azt jelenti, hogy több eredményhalmazt is ki lehet nyerni a DataReaderből, lásd a következő demókódot:
Több objektumot is visszaküldhetsz egyetlen válaszban egy webes API-ból, próbáld meg kombinálni a visszaküldött objektumokat, és a következő objektumokat küldöd vissza:
Ez csökkenti a HTTP kéréseket a WEB API-hoz.
Köszönöm, hogy elolvastad ezt a cikket.
|
Közzétéve 2016. 01. 11. 14:37:43
|
|
|
|
