Опубликован: 16.02.2009 | Доступ: свободный | Студентов: 1426 / 138 | Оценка: 4.26 / 4.17 | Длительность: 16:10:00
ISBN: 978-5-9963-0024-2
Лекция 2:

Уменьшение размера

Аннотация: В данной лекции Вы получите информацию об одной из основных техник оптимизации - архивировании. Здесь рассматриваются такие аспекты, как эффективность и издержки сжатия, приводятся практические рекомендации для оптимизированной конфигурации веб-серверов. Большое внимание в лекции уделено сжатию JavaScript и CSS файлов, а также сжатию изображений. Большое количество информации в лекции приводится в наглядной графической форме.

Насколько ресурсоемко архивирование HTML

Архивирование ( gzip- , deflate -сжатие) уже давно является наиболее известной техникой оптимизации. Однако применяют ее по-прежнему так же редко, как и 10 лет назад. Я постараюсь максимально подробно осветить проблемные аспекты использования сжатия на сервере и предложить возможные методы их решения.

Сжатие веб-содержимого посредством gzip ( GNU zip ) — это довольно старая технология. Суть ее сводится к тому, что содержимое перед отправкой пользователю сжимается по известному всем алгоритму zip. Сама спецификация gzip описана в RFC1952 (http://tools.ietf.org/html/rfc1952), версия 4.2 которой датируется маем 1996 года. На сегодняшний день все популярные браузеры и веб-серверы поддерживают сжатие посредством gzip.

Издержки на использование mod_gzip

Начиная с версии протокола http/1.1, веб-клиенты указывают, какие типы сжатия они поддерживают, устанавливая заголовок Accept-Encoding в http-запросе: Accept-Encoding: gzip, deflate.

Если веб-сервер видит такой заголовок в запросе, он может применить сжатие ответа одним из методов, перечисленных клиентом. При выдаче ответа посредством заголовка Content-Encoding сервер уведомляет клиента о том, каким методом сжимался ответ.

Content-Encoding: gzip

Переданные таким образом данные меньше первоначальных примерно в 5 раз, и это существенно ускоряет их доставку. Однако давайте рассмотрим следующий вопрос: как динамическое gzip-сжатие влияет на быстродействие сервера? Рентабельно ли включать mod_gzip / mod_deflate для высоконагруженных проектов? И в каких случаях архивирование лучше вообще не использовать?

Формализация модели

Для начала нужно было каким-либо образом установить издержки на само архивирование. Схематично эти накладные расходы можно представить примерно в следующем виде:

gzip = чтение / запись на диск + инициализация библиотеки
 + создание архива

Предполагается, что первые две составляющие не зависят от размера файла (в исследовании участвовали файлы от 500 байтов до 128 Кб), а являются более-менее постоянными (по сравнению с последним слагаемым). Однако, как оказалось, работы с файловой системой зависят от размера. Об этом чуть подробнее рассказывается ниже. Естественно, что процессорные ресурсы, уходящие на "создание архива", должны быть примерно линейными от размера файла (линейное приближение вносит погрешность не больше, чем остальные предположения), поэтому результирующая формула примет примерно такой вид:

gzip = FS + LI + K*size

Здесь FS — издержки на файловую систему, LI — издержки на инициализацию библиотеки и любые другие постоянные издержки, зависящие от реализации gzip, а K — коэффициент пропорциональности размера файла увеличению времени его архивирования.

Набор тестов

Итак, для проверки гипотезы и установления истинных коэффициентов нам потребуется 2 набора тестов:

  • Тесты на сжатие: для набора пар значений "size — gzip".
  • Тесты на запись: для набора пар значений "size — FS".

Почему именно 2 — а как же издержки на инициализацию архивирования, спросите вы? Потому что в таком случае у нас получится система (не)линейных уравнений, а найти из нее 2 неизвестных (коэффициент пропорциональности и статические издержки) не представляется сложным. Решать переопределенную систему и рассчитывать лишний раз точную погрешность измерения не требуется: статистическими методами погрешность и так сводится к минимуму.

Для тестирования был взят обычный HTML-файл (чтобы условия максимально соответствовали реальным). Затем из него были вырезаны первые 500, 1000 ... 128000 байтов. Все получившиеся файлы на сервере сначала в цикле архивировались нужное число раз, затем открывались и копировались на файловую систему — с помощью встроенных средств ОС Linux (cat, gzip), чтобы не добавлять дополнительных издержек какого-либо "внешнего" языка программирования.

Результаты тестирования

Для сжатия был получен следующий график. Хорошо заметно, что для небольших файлов основные издержки вносятся работой с файловой системой, а не архивированием. Здесь и далее все времена указаны в миллисекундах. Проводились серии тестов по 10000 итераций.

 График издержек на gzip-сжатие от размера файла

Рис. 2.1. График издержек на gzip-сжатие от размера файла

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

График издержек на gzip-сжатие и работу с файловой системой

Рис. 2.2. График издержек на gzip-сжатие и работу с файловой системой

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

График реальных и модельных издержек на gzip-сжатие

Рис. 2.3. График реальных и модельных издержек на gzip-сжатие

Пара слов о файловой системе

Вопрос: зачем нужны дополнительные тесты на производительность файловой системы, ведь уже есть характерное время, уходящее на gzip-сжатие определенных размеров файлов?

Ответ: во-первых, любой веб-сервер и так берет файл из файловой системы и архивирует уже в памяти, а потом пишет в сокет. Это время уже учтено при установлении соединения с сервером до получения первого байта. Нам лишь нужно понять, насколько оно увеличится, если сервер произведет еще некоторые операции с данными в оперативной памяти.

Во-вторых, не все серверы читают прямо с диска. У высоконагруженных систем и прокси-серверов (например, 0W, squid, nginx, thttpd ) данные могут храниться прямо в оперативной памяти, поэтому время доступа к ним существенно меньше, чем к файловой системе. Соответственно, его и нужно исключить из полученных результатов.

Что быстрее: gzip или канал?

Модель хорошо аппроксимирует полученные данные, поэтому примем ее за основу для следующих вычислений. Нам нужно, на самом деле, установить, насколько процессорные издержки на сжатие превосходят (или, наоборот, меньше) издержек на передачу несжатой информации. Для этого мы построим ряд графиков, приняв за эталон полученные коэффициенты для однопроцессорного сжатия на Dual Xeon 2,8 ГГц.

Так как с пользовательской стороны уходит некоторое время на распаковку архива, то ограничим его временем сжатия на машине с CPU в 1 ГГц. Это ограничение сверху: естественно, что распаковка экономичнее сжатия, да и пользовательские машины имеют процессоры в среднем мощнее, чем 1 ГГц. Однако нам нужно получить лишь качественные данные (ограничение снизу), поэтому ограничимся таким уровнем точности.

Итак, ниже приведены издержки на передачу дополнительного количества информации (в миллисекундах) для двух разных каналов (100 Кб/с и 1500 Кб/с) и двух разных серверов (280 МГц и 1 ГГц). Видно, что график для gzip на 1000 МГц идет практически вровень с передачей данных для канала в 1500 Кб/с (одна линия перекрывает другую).

Накладные издержки на сжатие и передачу информации для 100 Кб и 1500 Кб и 280 МГц и 1000 МГц

Рис. 2.4. Накладные издержки на сжатие и передачу информации для 100 Кб и 1500 Кб и 280 МГц и 1000 МГц

Исследование степени gzip-сжатия и загрузки процессора

Рассмотрим далее, насколько сильно издержки на gzip зависят от степени сжатия, и как их прогнозировать с учетом всех остальных параметров. Новая серия тестов была направлена на установление зависимости между степенью сжатия, процессорными издержками и уменьшением размера файла, чтобы на основе этих данных построить более точную модель, определяющую рациональность использования архивирования "на лету".

Как и ранее, на сервере проводились серии тестов по 10000 итераций в каждом. Замерялось время работы gzip при различных степенях сжатия. Затем оно усреднялось по серии, и из него вычитались издержки на работу с файловой системой. Также замерялось достигнутое уменьшение размера файла. Для зависимости "процессорное время — степень сжатия" был получен следующий график. По оси абсцисс идет степень сжатия, по оси ординат — затраченное время (среднее по серии):

 Зависимость издержек на gzip от степени сжатия

Рис. 2.5. Зависимость издержек на gzip от степени сжатия

Далее график эффективности полученного сжатия (в % от оригинального размера файлов) от степени сжатия:

 Эффективность различных степеней gzip-сжатия

Рис. 2.6. Эффективность различных степеней gzip-сжатия