Установка модуля pagespeed для Nginx на Debian 6

  • Tutorial
Уже несколько лет как Google выпустила модуль для Web-серверов Apache и Nginx, который представляет из себя набор фильтров и позволяет значительно повысить производительность сайта. В данном посте речь пойдет не о технологии и описании модуля, а о его установке и базовой настройке. Описание установки будет проведено только для Nginx. Установка модуля на Apache проста до безобразия и в данной статье не затрагивается.

Приступим


Устанавливаем необходимые пакеты:
apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev

Для начала создаем каталог на сервере, у меня это каталог» «temp»:
cd /temp
Загружаем и распаковываем исходники модуля:
wget github.com/pagespeed/ngx_pagespeed/archive/v1.7.30.1-beta.zip
unzip v1.7.30.1-beta.zip
cd ngx_pagespeed-1.7.30.1-beta
Загружаем и распаковываем PSOL:
wget dl.google.com/dl/page-speed/psol/1.7.30.1.tar.gz
tar -xzvf 1.7.30.1.tar.gz
Загружаем последнюю стабильную версию NGINX:
wget nginx.org/download/nginx-1.4.5.tar.gz
tar -xvzf nginx-1.4.5.tar.gz
cd nginx-1.4.5/

Далее важный момент, в большинстве случаев, при установке из репозиториев, nginx ставится в каталог /etc/nginx, однако при установке из исходников каталог установки отличается. Если ставите NGINX в первый раз это не критично, но если вы хотите обновить текущую версию, то необходимо прописать в явном виде пути, в моем случае следующий шаг:
./configure --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --sbin-path=/usr/sbin/nginx --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --http-scgi-temp-path=/var/lib/nginx/scgi --prefix=/var/lib/nginx --with-http_stub_status_module --with-http_flv_module --with-http_ssl_module --with-http_dav_module --with-http_sub_module --with-http_realip_module --with-http_gzip_static_module --with-http_secure_link_module --with-ipv6 --with-debug --add-module=/temp/ngx_pagespeed-1.7.30.1-beta

Убедившись в отсутствии ошибок выполняем установку:
make
checkinstall

Перезапускаем NGINX:
/etc/init.d/nginx restart
И проверяем, что мы обновились успешно: nginx –V

Настройка


После установки необходимо произвести первоначальную настройку конфигурационного файла nginx.conf:
В секцию http { … добавляем следующие директивы:
pagespeed on;
pagespeed FileCachePath "/var/cache/ngx_pagespeed/";
pagespeed EnableFilters combine_css,combine_javascript,rewrite_images,rewrite_css,rewrite_javascript,inline_images,recompress_jpeg,recompress_png,resize_images;
pagespeed JpegRecompressionQuality 85;
pagespeed ImageRecompressionQuality 85;
pagespeed ImageInlineMaxBytes 2048;
pagespeed LowercaseHtmlNames on;

Не забудьте создать каталог /var/cache/ngx_pagespeed/.
После чего снова делаем рестарт:
/etc/init.d/nginx restart

С описаниями фильтров и возможностей можно ознакомиться на официальной странице. При использовании фильтров обратите внимание на раздел «Risks».
В моем случае показатели производительности (согласно плагину для Firefox — pagespeed), увеличились на 25%.
Поделиться публикацией

Похожие публикации

Комментарии 17

    0
    Спасибо за хороший FAQ. Сразу вопрос. Я все читаю, и никак не могу понять, что значит «производительность увеличилась на 25%». Производительность чего? Можете пояснить?
      +1
      Вероятно, речь идёт о попугаях, в которых Гугл измеряет производительность сайта. В идеале, их должно быть сто, в данном случае — стало на 25 больше, чем было.
        0
        Под производительностью здесь подразумевается рейтинг Page Speed Score.
          +1
          Насколько при этом упала производительность nginx?
            0
            Как-то ради интереса попробовал на примере wawision (немецкая опенсорсная система управления товарами), код там так себе, но за то проект достаточно большой и есть все что хочешь — jquery, ajax, в меру кривой php и т.д.

            В результате после того как pagespeed cache устаканился (ни одного нового файла в кэше), протестировал нагрузку 5-ю воркерами (мерил server side, записывая в лог $request_time, по окончанию анализ и average по расширению):
            Под средней нагрузкой (порядка 4-5 request паралельно), отдача nginx просела на динамике:
            php  - с 0.052ms до 0.074ms
            ajax - с 0.009ms до 0.011ms
            

            статика:
            html - с 0.012ms до 0.034ms
            js   - с 0.003ms до 0.014ms
            css  - с 0.002ms до 0.004ms
            
            Графика кэшируется браузером (в location 1 year), поэтому мне была здесь совсем не интересна.

            Стрес-тест не устраивал, но думаю nginx (server side) просядет много хуже, хотя при высоком проценте статики либо количестве уникальных пользователей возможно и оправдано.

            В попугаях же (под firefox), прирост «скорости» стоставил порядка 17% (иногда почему-то до 20%), при незначительном уменьшении трафика (без gzip).

            Думается, каждый должен для себя и под конкретный проект решать, нужно оно или нет. Жалко, что оно не работает под location (только http и server), так-то можно было бы «тюнинг» чуть корректней настроить.
              0
              Учтите, что $request_time обновляется раз в итерацию цикла, таким образом предполагается, что все события обрабатываются мгновенно. Разумеется это не так и по-умолчанию там просто заложена определенная погрешность и она будет тем больше, чем более nginx оказался CPU-bound или заблокирован на I/O.

              Я бы не рассматривал $request_time как серьезный измерительный инструмент. Кроме того в это время также входит и время передачи ответа клиенту, которое зависит более от самого клиента, чем от nginx.

              Ожидаемый результат включения pagespeed — падение производительности nginx от 2 до 10 раз.
                0
                Учтите, что $request_time ...
                Ну это как-раз понятно.

                Специально для вас, протестировал отдачу полной странички wawision (благо конфиги остались).
                Делаю reload page (типа Ctrl+F5) — профилирую теперь прямо в лисе, гигабитная локалка (один на один на свиче):
                pagespeed on:
                  41 requests, 866,82 KB, 1,90 s - 2,02 s
                pagespeed off:
                  53 requests, 970,30 KB, 1,42 s - 1,44 s
                
                Странновато, но терпимо… (повторяю — делал полный reload).

                Теперь, клик (не reload) на ту же страницу (только не кэшируемая динамика, т.е. всего 2-а запроса php+ajax):
                pagespeed on:
                  3 requests, 81,19 KB, 0,46 s - 0,47 s  #  т.к. добавился еще ngx_pagespeed_beacon?url=...
                pagespeed off:
                  2 requests, 85,81 KB, 0,46 s - 0,50 s
                

                А можете прояснить момент с «до 10 раз»?
                  0
                  А можете прояснить момент «до 10 раз»?
                  Периодически люди в рассылку жалуются, мол что такое, запустил ab, а nginx только 10rps выдает.

                  Ваш тест абсолютно не показателен, поскольку до тех пор, пока процессора хватает — время ответа не будет существенно расти. Нагрузка пойдет и все превратится в тыкву.

                  Возьмите wrk и измерьте rps.

                  Пока, я так понимаю, вы только доказали, что с точки зрения времени загрузки страницы модуль делает только хуже.

                  Не надо вообще никакого внимания обращать на пузомерку «Page Speed Score», последняя выдает попугаи, которые лишь показывают в относительных единицах то, насколько по мнению гугла сайт можно было бы оптимизировать, но при этом если в результате этой оптимизации на лету у вас сервер начнет нещадно тормозить, пузомерка будет счастлива, а вот ваши пользователи — нет.
                    0
                    Я с вами практически согласен, и выводы у меня похожие. Смущало ваше это в 10 раз.
                    «Пузомерку» не использую принципиально. Под нагрузкой не тестировал — т.к. мне и этих показателей хватило. Еще раз цитата из моего же коммента:
                    Стрес-тест не устраивал, но думаю nginx (server side) просядет много хуже

                      0
                      Спасибо, что комментируете и критикуете! :)

                      Вот такой ответ на Ваш комментарий от инженеров команды PageSpeed (в моём перводе):

                      «Вполне возможно, что при большом количестве одновременных посетителей сайта или при синтетических тестах на пропускную способность HTML можно наблюдать снижение производительности. Но у большинства сайтов либо HTML генерируется динамически, либо они далеко не добирают до максимального уровня QPS (query per second) на статические файлы, и большинство запросов идущих на сервер идут на кэшируемые ресурсы, с которыми PageSpeed неплохо ​​справляется.

                      В любом случае Nginx следует «покрывать» varnish, как описано в developers.google.com/speed/pagespeed/module/downstream-caching»
                    0
                    Кроме того в это время также входит и время передачи ответа клиенту, которое зависит более от самого клиента, чем от nginx.
                    Не зависит там ничего: клиент — тоже асинхронный сишный дамми-скрипт на N воркеров, паралельно забирающих URL из списка, гигабит (один на один на свиче), без валидации, без аутенификации, совсем без ничего (даже в чистую дроп пробовал).
                0
                Тогда так и напишите в посте. А то если Page Speed Score был 50 а стал 75, то не на 25%, а на 50% скорость увеличилась.
                  +1
                  Я так и написал, что на моем примере рейтинг стал выше на 25%.
                    0
                    В таком случае все ясно. А то комментарий выше ввел в заблуждение.
              0
              Для тех, кто вдруг не хочет компилить и собирать это руками, делаем бэкап, добавляем в репу dotdeb, обновляемся, устанавливаем nginx-extras (там кроме всего прочего pagespeed), и начинаем от пункта «Настройка» из статьи.

              Кстати у меня прирост был только на 2.5 процента попугая — просто я тот еще оптимизатор (ну очень дотошный) и видимо все где можно уже поправил руками.
                +1
                Считаю правильней делать pagespeed «руками». Инструкций — океаны и моря. У тех же Google и Yahoo.
                  –1
                  Сам руками оптимизировал не один десяток сайтов, поэтому результаты ngx_pagespeed очень даже неплохие, по сравнению с ручной оптимизацией.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое