Несколько статей и переводов по оптимизации (gzip для Apache, gzip для CSS- и JS-файлов, CSS-сжатие, JS-сжатие) уже затрагивали тему применения архивирования для уменьшения размера файлов, и, тем самым, увеличения скорости их передачи конечному пользователю. В данном исследовании я задался вопросом: а как динамическое gzip-сжатие влияет на быстродействие сервера? Рентабельно ли включать mod_gzip / mod_deflate для высоконагруженных проектов? И в каких случаях архивирование вообще лучше не использовать?
Отдельно хочется сказать спасибо одному из читателей Хабра, который в личной переписке (к сожалению, исходное письмо безвозвратно потерялось, поэтому буду признателен, если он о себе напомнит) настойчиво пытался прояснить этот вопрос, что послужило отличным стимулом для написания данной статьи.
Для начала нужно было каким-либо образом установить издержки на само архивирование. В моем представлении, схематично эти накладные расходы можно представить примерно в следующем виде:
gzip = чтение/запись на диск + инициализация библиотеки + создание архива
Предполагается, что первые две составляющие не зависят от размера файла (в исследовании участвовали файлы от 500 байтов до 128 Кб), а являются более-менее постоянными (по сравнению с последним слагаемым). Однако, как оказалось, работы с файловой системой зависят от размера. Об этом чуть подробнее ниже.
Естественно, что процессорные ресурсы, уходящие на «создание архива», должны быть примерно линейными от размера файла (линейное приближение вносит погрешность не больше, чем остальные предположения), поэтому результирующая формула примет примерно такой вид:
gzip = FS + LI + K*size
Здесь FS — издержки на файловую систему, LI — издержки на инициализацию библиотеки и любые другие постоянные издержки, зависящие от реализации gzip, а K — коэффициент пропорциональности размера файла увеличению времени его архивирования.
Итак, для проверки гипотезы и установления истинных коэффициентов нам потребуется 2 набора тестов:
Почему именно 2, а как же издержки на инициализацию архивирования, спросите вы? Потому у нас получится система (не)линейных уравнений, а найти из нее 2 неизвестных (коэффициент пропорциональности и статические издержки) не представляется трудным. Решать переопределенную систему и рассчитывать лишний раз точную погрешность измерения не хочется, статистическими методами погрешность и так сводится к минимуму.
Для тестирования был взят обычный html-файл (чтобы условия максимально соответствовали реальным). Затем из него были вырезаны первые 500, 1000 ... 128000 байтов. Все получившиеся файлы на сервере сначала в цикле архивировались нужное число раз, затем открывались и копировались на файловую систему. Все с помощью встроенных средств ОС (cat, gzip), чтобы не добавлять дополнительных издержек какого-либо «внешнего» языка программирования.
Для сжатия был получен следующий график. Хорошо заметно, что для небольших файлов основных издержки вносятся работой с файловой системой, а не архивированием. Здесь и далее все времена указаны в миллисекундах. Проводились серии тестов по 10000 итераций.
Рисунок 1. График издержек на gzip-сжатие от размера файла
Теперь добавим исследования по работе с файловой системой, вычтем их из общих издержек и получим следующую картину:
Рисунок 2. График издержек на gzip-сжатие и работу с файловой системой
Издержки на открытие, запись, закрытие файла зависят в некоторой степени от размера, однако, нам это не мешает построить модельную зависимость вычислительной нагрузки от размера файла (предполагая, что в данном диапазоне она линейна). В результате, получим следующее:
Рисунок 3. График реальных и модельных издержек на gzip-сжатие
Вопрос: зачем нужны дополнительные тесты на производительность файловой системы, ведь уже есть характерное время, уходящее на gzip-сжатие определенных размеров файлов?
Ответ: во-первых, любой веб-сервер и так берет файл из файловой системы и архивирует уже в памяти, а потом пишет в сокет. Это время уже учтено при установлении соединения с сервером до получения первого байта. Нам лишь нужно понять, насколько оно увеличится, если сервер произведет еще некоторые операции с данными в оперативной памяти.
Во-вторых, не все сервера читают прямо с диска. Для высоконагруженных систем и прокси-серверов (squid, nginx, thttpd) данные хранятся прямо в оперативной памяти, поэтому время доступа к ним существенно меньше, чем к файловой системе. Соответственно, его и нужно исключить из полученных результатов.
Модель хорошо аппроксимирует полученные данные, поэтому примем ее за основу для следующих вычислений. Нам нужно, на самом деле, установить, насколько процессорные издержки на сжатие превосходят (или, наоборот, меньше) издержек на передачу несжатой информации. Для этого мы построим ряд графиков, приняв за эталон полученные коэффициенты для однопроцессорного сжатия на Dual Xeon 2,8 Ггц.
Так как с пользовательской стороны уходит некоторые время на распаковку архива, то ограничим его временем сжатия на машине в 1 Ггц (это ограничение сверху, на самом деле, естественно, расжатие экономичнее сжатия, да и пользовательские машины, в среднем, мощнее, чем 1Ггц, однако, нам нужно получить лишь качественные данные, поэтому ограничимся таким уровнем точности). Итак, ниже приведены издержки на передачу дополнительного количества информации (в миллисекундах) для двух разных каналов (100 Кб/с и 1500 Кб/с) и двух разных серверов (280 МГц и 1 Ггц).
Рисунок 4. Накладные издержки на сжатие и передачу информации для 100Кб и 1500Кб и 280МГц и 1000МГц
Собственно, картинки говорят сами за себя. Если у вас средние HTML-файлы больше 4 Кб, то уже появится ощутимый выигрыш для большинства пользователей при включенном gzip на сервере (даже если этот сервер находится на весьма «слабенькой» машине). В случае маленьких файлов и(ли) медленного в вычислениях сервера стоящего, однако, на быстром канале будет экономичнее не сжимать файлы.
Хочется также обратить внимание на то, что, отдав пользователю данные быстрее (через gzip-сжатие), мы тем самым освободим часть серверных ресурсов, что может оказаться существенным подспорьем для высонагруженных проектов.