Глава 2. Уменьшение размера
2.1. Насколько ресурсоемко архивирование HTML
проблемные аспекты использования сжатия на сервере и предложить возможные методы их решения.
Сжатие веб-содержимого посредством gzip (GNU zip) это довольно старая технология. Суть ее сводится к тому, что содержимое перед отправкой пользователю сжимается по известному всем алгоритму zip. Сама спецификация gzip описана в RFC1952 ( http://tools.ietf.org/html/rfc1952 ), версия 4.2 которой датируется маем 1996 года. На сегодняшний день все популярные браузеры и веб-серверы поддерживают сжатие посредством gzip.
Издержки на использование mod_gzip
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 коэффициент пропорциональности размера файла увеличению времени его архивирования.
Набор тестов
Тесты на сжатие: для набора пар значений «size gzip»
Тесты на запись: для набора пар значений «size FS»
Почему именно 2 а как же издержки на инициализацию архивирования, спросите вы? Потому что в таком случае у нас получится система (не)линейных уравнений, а найти из нее 2 неизвестных (коэффициент пропорциональности и статические издержки) не представляется сложным. Решать переопределенную систему и рассчитывать лишний раз точную погрешность измерения не требуется: статистическими методами погрешность и так сводится к минимуму.
Для тестирования был взят обычный HTML-файл (чтобы условия максимально соответствовали реальным). Затем из него были вырезаны первые 500, 1000 ... 128000 байтов. Все получившиеся файлы на сервере сначала в цикле архивировались нужное число раз, затем открывались и копировались на файловую систему с помощью встроенных средств ОС Linux (cat, gzip), чтобы не добавлять дополнительных издержек какого-либо «внешнего» языка программирования.
Результаты тестирования
все времена указаны в миллисекундахРис. 2.1 . График издержек на gzip-сжатие от размера файла
Теперь добавим исследования по работе с файловой системой, вычтем
их из общих издержек и получим следующую картину.
Рис. 2.2 . График издержек на gzip-сжатие и работу с файловой системой
Издержки на открытие, запись, закрытие файла зависят в некоторой степени от размера, однако это не мешает нам построить модельную зависимость вычислительной нагрузки от размера файла (предполагая, что в данном диапазоне она линейна). В результате получим следующее (рис. 2.3).
Рис. 2.3 . График реальных и модельных издержек на gzip-сжатие
Пара слов о файловой системе
ВопросОтвет: во-первых, любой веб-сервер и так берет файл из файловой системы и архивирует уже в памяти, а потом пишет в сокет. Это время уже учтено при установлении соединения с сервером до получения первого байта. Нам лишь нужно понять, насколько оно увеличится, если сервер произведет еще некоторые операции с данными в оперативной памяти.
Во-вторых, не все серверы читают прямо с диска. У высоконагруженных систем и прокси-серверов (например, 0W, squid, nginx, thttpd) данные могут храниться прямо в оперативной памяти, поэтому время доступа к ним существенно меньше, чем к файловой системе. Соответственно, его и нужно исключить из полученных результатов.