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

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

Сжатие веб-содержимого посредством gzip (GZU 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 набора тестов:

1. Тесты на сжатие для набора пар значений «ize - gzip»
2. Тесты на запись для набора пар значений «ize - FS»

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

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

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

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

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

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

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

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