Вимоги: HTTP тепер додає алгоритм стиснення Brotli для тестування алгоритмів Gzip і Brotli. Залежно від проєкту, у статті перевіряється лише швидкість декомпресії.
Бротлі мав12 рівнів стиснення, від 0 до 11, де 0 забезпечує найвищу швидкість стиснення, але найнижчий ступінь стиснення, а 11 — найвищий ступінь стиснення, але потребує більше обчислювальних ресурсів і часу. Коли ми вперше впровадили Brotli 5 років тому, ми визначили, що чотирирівневе стиснення забезпечує баланс між економією байтів і часом стиснення без погіршення продуктивності. Чим вищий рівень стиснення, тим менший випадок, але це продає більше ресурсів процесора та пам'яті.
ASP.NET алгоритм Brotli вже вбудований у ядро і не потребує посилання на сторонні пакети. (У цій статті йдеться про сторонній пакет: BrotliSharpLib та вбудований для порівняння), конфігурація виглядає так:
ASP.NET Core Brotli компресійний потік: ResponseCompressionServicesExtensions -> AddResponseCompression -> ResponseCompressionProvider -> BrotliCompressionProvider -> BrotliStream.
Код для перерахування рівня стиснення виглядає так:
Створіть новий проєкт консолі .NET 6 з таким кодом бенчмарку:
Результати тесту такі:
Я протестував файл на 503kb, і після стиснення різниці майже не було — близько 400kb, і виявилося, що швидкість декомпресії Gzip все одно вища, ніж у Brotli, яка мала б бути такою жРозмір файлу, . Версія NET, рівень стиснення, вміст файлу тощоКоротко кажучи, найкраще обрати сцену, яка вам підходить.
Якщо ви зіткнулися з помилкою, подібною до ця:
Середовище
Резюме -> Виявлено код виходу з помилки з одного з бенчмарків. Це може бути спричинено наступним антивірусним програмним забезпеченням:
- 360 SafeGuard (C:\Program Files (x86)\360\360Safe\safemon\360tray.exe)
- Windows Defender (windowsdefender://)
Використовуйте InProcessEmitToolchain або InProcessNoEmitToolchain, щоб уникнути створення нових процесів.
або
(Кінець)
|
Опубліковано 17.09.2023 10:45:34
|
|
|
|
Орендодавець|
Опубліковано 17.09.2023 10:46:46
|
