Krav: HTTP legger nå til en Brotli-komprimeringsalgoritme for å teste Gzip- og Brotli-algoritmer. Avhengig av prosjektet testes kun dekomprimeringshastigheten i artikkelen.
Brotli har12 nivåer av kompresjon, fra 0 til 11, hvor 0 gir raskest komprimeringshastighet men lavest komprimeringsforhold, mens 11 gir høyest kompresjonsforhold, men krever mer datakraft og tid. Da vi først implementerte Brotli for 5 år siden, konkluderte vi med at 4-nivås komprimering ga en balanse mellom bytebesparelser og komprimeringstid uten å gå på bekostning av ytelsen. Jo høyere komprimeringsnivå, desto mindre fotavtrykk, men det selger flere CPU- og minneressurser.
ASP.NET Brotli-algoritmen er allerede innebygd i kjernen og krever ikke referanse til tredjepartspakker. (Denne artikkelen vil referere til tredjepartspakken: BrotliSharpLib og den innebygde for sammenligning), konfigurasjonen er som følger:
ASP.NET Kjerne Brotli komprimeringskallflyt: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
Kompresjonsnivå-oppramsningskoden er som følger:
Lag et nytt .NET 6-konsollprosjekt med følgende benchmark-kode:
Testresultatene er som følger:
Jeg testet en 503kb-fil, og etter komprimering var det ikke så stor forskjell, rundt 400kb, og det viste seg at Gzips dekomprimeringshastighet fortsatt var raskere enn Brotlis, som burde være den sammefilstørrelse. NET-versjon, komprimeringsnivå, filinnhold osvKort sagt, det er best å velge den scenen som passer deg.
Hvis du støter på en slik feil:
Miljø
Sammendrag -> Oppdaget feilavslutningskode fra en av benchmarkene. Det kan skyldes følgende antivirusprogramvare:
- 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe)
- Windows Defender (windowsdefender://)
Bruk InProcessEmitToolChain eller InProcessNoEmitToolchain for å unngå ny prosessopprettelse.
eller
(Slutt)
|
Publisert på 17.09.2023 10:45:34
|
|
|
|
Vert|
Publisert på 17.09.2023 10:46:46
|
