Követelmények: A HTTP most egy Brotli tömörítési algoritmust ad hozzá a Gzip és Brotli algoritmusok teszteléséhez. A projekttől függően csak a dekompresszió sebességét tesztelik a cikkben.
Brotli12 tömörítési szint, 0-tól 11-ig, ahol 0 adja a leggyorsabb tömörítési sebességet, de a legalacsonyabb tömörítési arányt, míg a 11 a legmagasabb tömörítési arányt, de több számítási erőforrást és időt igényel. Amikor 5 évvel ezelőtt először vezettük be a Brotlit, megállapítottuk, hogy a 4 szintű tömörítés egyensúlyt biztosít a bájtmegtakarítás és a tömörítési idő között, anélkül, hogy a teljesítményt romítaná. Minél magasabb a tömörítési szint, annál kisebb a lábnyom, de több CPU és memória erőforrást ad el.
ASP.NET Brotli algoritmus már be van építve a magba, és nem igényel hivatkozást harmadik fél csomagjaira. (Ez a cikk a harmadik féltől származó csomagra vonatkozik: BrotliSharpLib és a beépített csomag összehasonlításuk), a konfiguráció a következő:
ASP.NET Core Brotli tömörítési hívás folyamata: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
A tömörítési szintű felsorolási kód a következő:
Hozz létre egy új .NET 6 konzolprojektet az alábbi benchmark kóddal:
A teszteredmények a következők:
Teszteltem egy 503 kb-os fájlt, és tömörítés után nem volt sok különbség, kb. 400 kb, és kiderült, hogy a Gzip dekompressziója még mindig gyorsabb volt, mint a Brotlié, ami ugyanannak kellene lenniefájlméret, . NET verzió, tömörítési szint, fájltartalom stbRöviden, a legjobb, ha azt a jelenetet választod, ami neked ille.
Ha ilyen hibával találkozol:
Környezet Összefoglaló -> Hiba kilépési kódot észleltek az egyik benchmarkból. Lehet, hogy a következő vírusirtó szoftverek okozzák: - 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe) - Windows Defender (windowsdefender://) Használd az InProcessEmitToolchain vagy az InProcessNoEmitToolchain programokat, hogy elkerüld az új folyamatok létrehozását. megoldás
vagy
(Vége)
|