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

    Статья «Как gzip-сжатие влияет на производительность сервера» вызвала вполне понятную, но несколько неоднозначную реакцию, ибо было не понятно, насколько сильно издержки на gzip зависят от степени сжатия и как ее прогнозировать с учетом всех остальных параметров. Хочется сказать отдельное спасибо посмотреть профиль alfa, который, собственно, и поднял этот вопрос.

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

    Методика



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

    Результаты



    Для зависимости «процессорное время — степень сжатия» был получен следующий график. По оси абсцисс идет степень сжатия, по оси ординат — затраченное время (среднее по серии):

    Издержки на gzip от степени сжатия

    Рисунок 1. Издержки на gzip от степени сжатия

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

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

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

    Выводы



    Основные выводы не отличаются от полученных в предыдущей статье, однако, удалось несколько уточнить (за счет того, что при задании различных степеней сжатия процессорные издержки могут варьироваться в разы). Все полученные выводы применены в следующем инструменте для расчета оптимальной степени gzip-сжатия для сервера (и вообще, рациональности включения gzip). Параметры, которые можно варьировать: CPU 1 процессора на сервере (ибо gzip не параллелится), CPU пользовательской машины и характерная скорость канала у пользователей. Различные их варианты покрывают достаточно широкий диапазон возможных случаев, а погрешность расчета не превосходит 10%.

    Маленькое замечание: если размер текстовых файлов на сервере не превосходит 4Кб, то включение gzip вообще не даст ощутимого выигрыша производительности.

    Спасибо всем, кто ознакомился с заметкой. Если у вас появятся предложения по усовершенствованию данного инструмента, напишите их, пожалуйста.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      0
      Я честно не понимаю почему gzip считается лучшим сжатием....
      Ведь при включенном gzip при переходе "Назад" в браузере страница грузится зпново, а без gzip берется из кеша...
      За статью спасибо
        +2
        Хм, а почему с gzip страница грузится заново? И какой броузер так делает?
          0
          Какая взаимосвязь между gzip и кешем?
            0
            Зависимость такая, что, например, IIS отключает по умолчанию кеширование при сжатии файлов. Это связанно с тем, что файл может закешироваться на каком-нить прокси и, если клиент не поддерживает gzip, то он никак не сможет получить нормальную несжатую версию файла. В связи с этим и не советуют включать кеширование для сжатых файлов.

            When you enable HTTP compression, compressed files are given a default expiration date of Jan. 1, 1997. This expiration date prevents proxy servers from serving cached copies of compressed files to browsers that are not compression-enabled.

            Хотя, думаю, можно просто обойтись Cache Control: Private.
              0
              я тоже поддерживаю последний способ. Хотя проблем, которые описываются таким стечением обстоятельств, реально, очень мало (<0,1%).
                0
                Прокси разве не должен смотреть на accept-encoding?
                  0
                  Мне кажется ему пофиг :)
              0
              1) далеко не все юзеры пользуются кнопкой назад
              2) не на всех сайтах есть такая необходимость
              3) тот маленький процент страниц, которые будут запрошены в результате нажатия кнопки "назад" не сэкономят траффик так, как это делает компрессия. На некоторых сайтах компрессия экономит траффик в 5 раз, бывает и больше. Вот грубо если посчитать, одна такая зазипованная странница оправдает 5 раз нажатие кнопки назад :)
                0
                По первому пункту. Откуда информация?
                  0
                  Сразу ссылку не приведу, но слышал не из одного источника. Вот последний - это Бобук в интервью с разработчиком IE. Он там цифру называл на основе яндексовских наблюдений. Понятно, что не последняя инстанция, но тенденция, я думаю, есть к этому.
                    0
                    Сильно зависит от того, как сайт построен. Я действительно на яндексе не пользуюсь кнопкой назад — там это просто незачем.
                      0
                      Согласен с вами. Я не утверждаю, что мои предположения — 100% точные расчеты.
              0
              Рисунок 1. Издержки на gzip от степени сжатия
              А какого размера тестовая страничка сжимается?
                0
                около 60 Кб. В первом исследовании — от 500 до 128000 байтов
                0
                Идеальный рецепт :)
                1) для css и js использовать модуль http_gzip_static_module в nginx. для браузеров, поддерживающих сжатие отдает уже заранее приготовленный gz (степень сжатия = 9)
                2) для динамики использовать динамическое сжатие в nginx-е со степенью сжатия = 1
                  0
                  Я думаю единица маловато, ведь затраченное время и процессор вернутся из-за того, что нужно передать меньше данных.
                    0
                    Судя по графикам, если увеличить степень сжатия с 1 до 6, то ответ будет меньше всего на 4%, зато время создания/загрузка процессора увеличится на 100%, то есть, в 2 раза.
                      0
                      я сжимал css, js, html на 6-ке сжатие
                      улучшилось на 22.3, 12.6, 12.6
                      для другого проекта 9.8, 18.8, 12.7
                        0
                        А как считалось разница - в процентах от исходного файла ? Можно привести примеры ? Например, берём prototype-1.6.0.2.js - 126127 байт, gzip -1 - 36182, gzip -6 - 29206. Получаем 71.3% и 76.8%.
                          0
                          if (! $files = scandir('./files/')) die('not exist \'./files/\'');
                          $times = array();
                          foreach($files AS $v) {
                          if ($v == '.' || $v == '..') continue;
                          $content = file_get_contents('./files/'.$v);
                          for($i=1;$i





                          -



                            0
                            Упс, извиняюсь, хотел весь скриптик всунуть, чтобы другие могли потестить.
                            сравниваю примерно так: от размера файла сжатого с степенью 1 отнимаю размер со сжатием 6 и результат делю на размер со степенью 1.
                            ajax.js 1 - 2803 2 - 2.7 3 - 4 4 - 7.7 5 - 9.6 6 - 9.8 7 - 9.8 8 - 9.8 9 - 9.8
                            bm.my.htm 1 - 4845 2 - 5 3 - 6.7 4 - 10.6 5 - 16.4 6 - 18.8 7 - 19.2 8 - 20.1 9 - 20.1
                            style.css 1 - 707 2 - 1.8 3 - 4 4 - 9.3 5 - 11.7 6 - 12.7 7 - 12.9 8 - 12.9 9 - 12.9
                              0
                              Я это и предполагал. Считать разницу имеет смысл от полного размера, а не от сжатого со степенью 1.
                                0
                                Я думаю, сравнивая два метода, логичнее было бы сравнивать их результаты. В данном случае я вижу, что сжатие 6 поможет сократить трафик на 10-15 процентов, оборотно стороной является значительная загрузка процессора по сравнению с степенью 1.
                          0
                          в большинстве случаев, загрузка процессора не настолько существенна
                            0
                            В большинсве случаев на загрузку гзипом можно начхать :)
                            Всеравно страница генериться как минимум раз так в 5-6-7 дольше.
                            Средне по рунету - начиная от 100 раз дольше( если брать время работы гзипа 14мсек)
                              0
                              :) там ошибка в графике была. Время работы 10000 итерация было в секундах, соответственно, время на сжатие 60Кб на сервере было порядка 1-2мс, что совсем мало :)
                                0
                                Ну тоесть на это время еще малек(раз так в десять) "побарабаней" :)
                            +1
                            Игорь, небольшой оффтоп: когда планируется релиз версии nginx с кешированием?

                      Only users with full accounts can post comments. Log in, please.