Каково влияние gzip на скорость передачи файлов по HTTP? - PullRequest
23 голосов
/ 16 сентября 2011

Я знаю, что сжатие файлов перед их отправкой по сети экономит полосу пропускания, а для статических файлов, которые можно кэшировать, это не оказывает существенного влияния на использование ЦП на стороне сервера.

А как же клиент? Они должны заархивировать любые файлы, которые будут отправлены, что займет процессорное время. Кроме того, я обеспокоен тем, что весь файл должен быть получен и распакован до того, как будет выполнен любой анализ.

Это кажется мне странным, потому что я вижу два сценария:

1) client has fast internet   -->   gzip is relevant
2) client has slow internet   -->   gzip prevents partial parsing

Очевидно, что точное ускорение (или замедление?) Будет зависеть от точных обстоятельств передаваемых файлов и клиента. Однако мне любопытно, сколько времени (или как я могу измерить стоимость) на стороне клиента?

Ответы [ 2 ]

38 голосов
/ 16 сентября 2011

Они должны распаковать все отправленные файлы, что займет процессорное время.

Возможно, но процессорное время, затрачиваемое на распаковку, чрезвычайно мало по сравнению со всеми другими вещами, происходящими при загрузке страницы (разбор, стилизация, рендеринг, создание сценариев).

Я беспокоюсь, что весь файл должен быть получен и заархивирован, прежде чем можно будет выполнить любой анализ.

Не волнуйтесь, gzip - это «поток» данных, и полный файл не требуется для начала распаковки / разбора.

В частности, я хочу знать, как я могу измерить, сколько времени теряется из-за gzipping.

Вот интересная статья , где автор выполняет тип теста, который вы описываете. Инструменты доступны для загрузки, поэтому вы можете выполнять те же тесты в своей среде.

Автор делает вывод:

Я полагаю, что очень мало случаев, когда вы не должны использовать gzip-контент. Если ваша обычная страница меньше 100 байт, то ее сжатие может ухудшить производительность клиента и сервера. Но ни один веб-сайт, за исключением, может быть, нескольких веб-служб, не обслуживает страницы с типичным размером 100 байт или менее. Так что нет никакого оправдания для обслуживания несжатого HTML.

19 голосов
/ 08 сентября 2015

В то же время (вопрос уже устарел), большинство людей в любом случае используют TLS для каждого соединения, поэтому вопросы о производительности стали немного излишними.Но все же стоит взглянуть на это:

1) у клиента быстрый интернет -> уместен gzip
2) у клиента медленный интернет -> gzip предотвращает частичный анализ

Дело обстоит иначе. Чем медленнее интернет-соединение клиента (или маршрут к серверу), тем больше преимуществ вы получаете от сжатия gzip (или сжатия в целом).

Сжатие полезно, если время, необходимое для сжатия / распаковки, плюс время, необходимое для передачи сжатых данных, меньше, чем время, необходимое для прямой передачи несжатых данных.

Gzip обычно сокращает вашиданные где-то между 1/3 и 1/2 от своего первоначального размера (в зависимости от того, что это такое), а сжатие выполняется со скоростью около 50 МБ / с (+/- 5).Декомпрессия примерно в 3 раза быстрее.

100 Мбит Ethernet имеет пропускную способность около 12,5 МБ / с, и большинство людей еще не имеют 100 Мбит доступа в Интернет (который, поскольку он обычно устанавливается поверх ATM, медленнеечем обычный Ethernet тоже).Кроме того, большинство людей в большинстве случаев не могут полностью насытить свое высокоскоростное интернет-соединение с помощью одной загрузки.

Таким образом, реально для обычного обычного пользователя и сервера, который не находится в вашей локальной сети.дома, но «где-то еще», скажем, вы получаете 5 МБ / с (что примерно вдвое больше теоретического максимума, который у меня здесь есть, кстати).

Для передачи файла размером 50 КБ вам, таким образом, потребуется 0,01 секунды.Сжатие gzip добавляет примерно 0,001 секунды к сжатию и 0,0003 секунды к распаковке (давайте округлим и скажем всего 0,002), но вам нужно всего лишь передать 16 КБ, что занимает 0,0032 секунды.

Добавьте их вместе, передайте с помощью gzipсжатие примерно в два раза быстрее.

Теперь, конечно, со временем (когда у обычного пользователя будет примерно 200 Мбит / с Интернета, а на серверах - 100 Гбит / с с восходящей связью) эта цифра обернется.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...