Zahteve: HTTP zdaj dodaja Brotli algoritem za stiskanje za testiranje algoritmov Gzip in Brotli. Glede na projekt se v članku preizkuša le hitrost dekompresije.
Brotli ima12 stopenj kompresije, od 0 do 11, kjer 0 zagotavlja najhitrejšo hitrost stiskanja, a najnižje razmerje stiskanja, medtem ko 11 zagotavlja najvišje razmerje stiskanja, vendar zahteva več računalniških virov in časa. Ko smo pred 5 leti prvič uvedli Brotli, smo ugotovili, da štirinivojska kompresija zagotavlja ravnovesje med prihrankom bajta in časom stiskanja brez kompromisa pri delovanju. Višja kot je raven stiskanja, manjši je odtis, vendar proda več CPU in pomnilniških virov.
ASP.NET Brotli algoritem je že vgrajen v jedro in ne zahteva sklicevanja na pakete tretjih oseb. (Ta članek se bo za primerjavo skliceval na paket tretje osebe: BrotliSharpLib in vgrajenega), konfiguracija je naslednja:
ASP.NET Osnovni tok stiskanja klica Brotli: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
Koda za enumeracijo ravni stiskanja je naslednja:
Ustvarite nov .NET 6 konzolni projekt z naslednjo testno kodo:
Rezultati testa so naslednji:
Testiral sem 503kb datoteko in po kompresiji ni bilo velike razlike, okoli 400kb, in izkazalo se je, da je bila hitrost dekompresije pri Gzipu še vedno hitrejša od Brotlijeve, kar bi moralo biti enakovelikost datoteke, . NET različica, raven stiskanja, vsebina datotek itdNa kratko, najbolje je izbrati prizor, ki vam najbolj ustreza.
Če naletite na takšno napako:
Okolje Povzetek -> Zaznana izhodna koda napake iz enega od testov. Vzrok je lahko naslednja protivirusna programska oprema: - 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe) - Windows Defender (windowsdefender://) Uporabite InProcessEmitToolchain ali InProcessNoEmitToolchain, da se izognete ustvarjanju novih procesov. rešitev
ali
(Konec)
|