Krav: HTTP lägger nu till en Brotli-komprimeringsalgoritm för att testa Gzip- och Brotli-algoritmer. Beroende på projektet testas endast dekompressionshastigheten i artikeln.
Brotli har12 nivåer av kompression, från 0 till 11, där 0 ger snabbast komprimeringshastighet men lägsta komprimeringsförhållande, medan 11 ger högst komprimeringsförhållande men kräver mer beräkningsresurser och tid. När vi först implementerade Brotli för 5 år sedan fastställde vi att fyrnivåkomprimering gav en balans mellan bytebesparingar och komprimeringstid utan att kompromissa med prestandan. Ju högre komprimeringsnivå, desto mindre fotavtryck, men den säljer fler CPU- och minnesresurser.
ASP.NET Brotli-algoritmen är redan inbyggd i kärnan och kräver ingen referens till tredjepartspaket. (Denna artikel kommer att referera till tredjepartspaketet: BrotliSharpLib och det inbyggda för jämförelse), konfigurationen är följande:
ASP.NET Core Brotli komprimeringsanropsflöde: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
Komprimeringsnivåns uppräkningskod är följande:
Skapa ett nytt .NET 6-konsolprojekt med följande benchmarkkod:
Testresultaten är följande:
Jag testade en 503kb-fil, och efter komprimeringen var det inte mycket skillnad, allt runt 400kb, och det visade sig att Gzips dekomprimeringshastighet fortfarande var snabbare än Brotlis, vilket borde vara densammafilstorlek, . NET-version, komprimeringsnivå, filinnehåll, etcKort sagt, det är bäst att välja den scen som passar dig.
Om du stöter på ett fel som detta:
Miljö Sammanfattning - > Upptäckt felutgångskod från en av benchmarkarna. Det kan orsakas av följande antivirusprogram: - 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe) - Windows Defender (windowsdefender://) Använd InProcessEmitToolchain eller InProcessNoEmitToolchain för att undvika ny processskapande. lösning
eller
(Slut)
|