Krav: HTTP tilføjer nu en Brotli-komprimeringsalgoritme til at teste Gzip- og Brotli-algoritmerne. Afhængigt af projektet testes kun dekompressionshastigheden i artiklen.
Brotli har12 kompressionsniveauer, fra 0 til 11, hvor 0 giver den hurtigste kompressionshastighed, men det laveste kompressionsforhold, mens 11 giver det højeste kompressionsforhold, men kræver flere computerressourcer og mere tid. Da vi først implementerede Brotli for 5 år siden, fastslog vi, at 4-niveaus komprimering gav en balance mellem bytebesparelser og komprimeringstid uden at gå på kompromis med ydeevnen. Jo højere komprimeringsniveau, desto mindre fodaftryk, men det sælger flere CPU- og hukommelsesressourcer.
ASP.NET Brotli-algoritmen er allerede indbygget i kernen og kræver ikke reference til tredjepartspakker. (Denne artikel vil referere til tredjepartspakken: BrotliSharpLib og den indbyggede til sammenligning), konfigurationen er som følger:
ASP.NET Core Brotli komprimeringskaldsflow: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
Komprimeringsniveauets opremsningskode er som følger:
Opret et nyt .NET 6-konsolprojekt med følgende benchmark-kode:
Testresultaterne er som følger:
Jeg testede en 503kb-fil, og efter komprimering var der ikke den store forskel, alt omkring 400kb, og det viste sig, at Gzips dekompressionshastighed stadig var hurtigere end Brotlis, hvilket burde være det sammefilstørrelse, . NET-version, komprimeringsniveau, filindhold osvKort sagt er det bedst at vælge den scene, der passer til dig.
Hvis du støder på en fejl som denne:
Miljø Resumé -> Opdaget fejludgangskode fra en af benchmarks. Det kan skyldes følgende antivirussoftware: - 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe) - Windows Defender (windowsdefender://) Brug InProcessEmitToolchain eller InProcessNoEmitToolchain for at undgå ny procesoprettelse. opløsning
eller
(Slut)
|