Статья «Как gzip-сжатие влияет на производительность сервера» вызвала вполне понятную, но несколько неоднозначную реакцию, ибо было не понятно, насколько сильно издержки на gzip зависят от степени сжатия и как ее прогнозировать с учетом всех остальных параметров. Хочется сказать отдельное спасибо 
alfa, который, собственно, и поднял этот вопрос.
Итак, новая серия тестов была направлена на установление зависимости между степенью сжатия, процессорными издержками и уменьшением размера файла, чтобы на основе этих данных сделать аналитический инструмент для вычисления оптимальной степени сжатия.
Как и ранее, на сервере проводились серии тестов по 10000 итераций в каждом. Замерялось время работы gzip при различных степенях сжатия. Затем оно усреднялось по серии, и из него вычитались издержки на работу с файловой системой (подробнее про издержки в предыдущей статье). Также замерялось достигнутое уменьшение размера файла.
Для зависимости «процессорное время — степень сжатия» был получен следующий график. По оси абсцисс идет степень сжатия, по оси ординат — затраченное время (среднее по серии):
Рисунок 1. Издержки на gzip от степени сжатия
Далее график эффективности полученного сжатия (в % от оригинального размера файлов) от степени сжатия:
Рисунок 2. Эффективность различных степеней gzip-сжатия
Основные выводы не отличаются от полученных в предыдущей статье, однако, удалось несколько уточнить (за счет того, что при задании различных степеней сжатия процессорные издержки могут варьироваться в разы). Все полученные выводы применены в следующем инструменте для расчета оптимальной степени gzip-сжатия для сервера (и вообще, рациональности включения gzip). Параметры, которые можно варьировать: CPU 1 процессора на сервере (ибо gzip не параллелится), CPU пользовательской машины и характерная скорость канала у пользователей. Различные их варианты покрывают достаточно широкий диапазон возможных случаев, а погрешность расчета не превосходит 10%.
Маленькое замечание: если размер текстовых файлов на сервере не превосходит 4Кб, то включение gzip вообще не даст ощутимого выигрыша производительности.
Спасибо всем, кто ознакомился с заметкой. Если у вас появятся предложения по усовершенствованию данного инструмента, напишите их, пожалуйста.
alfa, который, собственно, и поднял этот вопрос.Итак, новая серия тестов была направлена на установление зависимости между степенью сжатия, процессорными издержками и уменьшением размера файла, чтобы на основе этих данных сделать аналитический инструмент для вычисления оптимальной степени сжатия.
Методика
Как и ранее, на сервере проводились серии тестов по 10000 итераций в каждом. Замерялось время работы gzip при различных степенях сжатия. Затем оно усреднялось по серии, и из него вычитались издержки на работу с файловой системой (подробнее про издержки в предыдущей статье). Также замерялось достигнутое уменьшение размера файла.
Результаты
Для зависимости «процессорное время — степень сжатия» был получен следующий график. По оси абсцисс идет степень сжатия, по оси ординат — затраченное время (среднее по серии):
Рисунок 1. Издержки на gzip от степени сжатия
Далее график эффективности полученного сжатия (в % от оригинального размера файлов) от степени сжатия:
Рисунок 2. Эффективность различных степеней gzip-сжатия
Выводы
Основные выводы не отличаются от полученных в предыдущей статье, однако, удалось несколько уточнить (за счет того, что при задании различных степеней сжатия процессорные издержки могут варьироваться в разы). Все полученные выводы применены в следующем инструменте для расчета оптимальной степени gzip-сжатия для сервера (и вообще, рациональности включения gzip). Параметры, которые можно варьировать: CPU 1 процессора на сервере (ибо gzip не параллелится), CPU пользовательской машины и характерная скорость канала у пользователей. Различные их варианты покрывают достаточно широкий диапазон возможных случаев, а погрешность расчета не превосходит 10%.
Маленькое замечание: если размер текстовых файлов на сервере не превосходит 4Кб, то включение gzip вообще не даст ощутимого выигрыша производительности.
Спасибо всем, кто ознакомился с заметкой. Если у вас появятся предложения по усовершенствованию данного инструмента, напишите их, пожалуйста.
