Comments 17
UFO just landed and posted this here
Вероятно, речь идёт о попугаях, в которых Гугл измеряет производительность сайта. В идеале, их должно быть сто, в данном случае — стало на 25 больше, чем было.
Под производительностью здесь подразумевается рейтинг Page Speed Score.
Насколько при этом упала производительность nginx?
Как-то ради интереса попробовал на примере wawision (немецкая опенсорсная система управления товарами), код там так себе, но за то проект достаточно большой и есть все что хочешь — jquery, ajax, в меру кривой php и т.д.
В результате после того как pagespeed cache устаканился (ни одного нового файла в кэше), протестировал нагрузку 5-ю воркерами (мерил server side, записывая в лог $request_time, по окончанию анализ и average по расширению):
Под средней нагрузкой (порядка 4-5 request паралельно), отдача nginx просела на динамике:
статика:
Стрес-тест не устраивал, но думаю nginx (server side) просядет много хуже, хотя при высоком проценте статики либо количестве уникальных пользователей возможно и оправдано.
В попугаях же (под firefox), прирост «скорости» стоставил порядка 17% (иногда почему-то до 20%), при незначительном уменьшении трафика (без gzip).
Думается, каждый должен для себя и под конкретный проект решать, нужно оно или нет. Жалко, что оно не работает под location (только http и server), так-то можно было бы «тюнинг» чуть корректней настроить.
В результате после того как 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
Стрес-тест не устраивал, но думаю nginx (server side) просядет много хуже, хотя при высоком проценте статики либо количестве уникальных пользователей возможно и оправдано.
В попугаях же (под firefox), прирост «скорости» стоставил порядка 17% (иногда почему-то до 20%), при незначительном уменьшении трафика (без gzip).
Думается, каждый должен для себя и под конкретный проект решать, нужно оно или нет. Жалко, что оно не работает под location (только http и server), так-то можно было бы «тюнинг» чуть корректней настроить.
Учтите, что $request_time обновляется раз в итерацию цикла, таким образом предполагается, что все события обрабатываются мгновенно. Разумеется это не так и по-умолчанию там просто заложена определенная погрешность и она будет тем больше, чем более nginx оказался CPU-bound или заблокирован на I/O.
Я бы не рассматривал $request_time как серьезный измерительный инструмент. Кроме того в это время также входит и время передачи ответа клиенту, которое зависит более от самого клиента, чем от nginx.
Ожидаемый результат включения pagespeed — падение производительности nginx от 2 до 10 раз.
Я бы не рассматривал $request_time как серьезный измерительный инструмент. Кроме того в это время также входит и время передачи ответа клиенту, которое зависит более от самого клиента, чем от nginx.
Ожидаемый результат включения pagespeed — падение производительности nginx от 2 до 10 раз.
Учтите, что $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) на ту же страницу (только не кэшируемая динамика, т.е. всего 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 раз»?
А можете прояснить момент «до 10 раз»?Периодически люди в рассылку жалуются, мол что такое, запустил ab, а nginx только 10rps выдает.
Ваш тест абсолютно не показателен, поскольку до тех пор, пока процессора хватает — время ответа не будет существенно расти. Нагрузка пойдет и все превратится в тыкву.
Возьмите wrk и измерьте rps.
Пока, я так понимаю, вы только доказали, что с точки зрения времени загрузки страницы модуль делает только хуже.
Не надо вообще никакого внимания обращать на пузомерку «Page Speed Score», последняя выдает попугаи, которые лишь показывают в относительных единицах то, насколько по мнению гугла сайт можно было бы оптимизировать, но при этом если в результате этой оптимизации на лету у вас сервер начнет нещадно тормозить, пузомерка будет счастлива, а вот ваши пользователи — нет.
Я с вами практически согласен, и выводы у меня похожие. Смущало ваше это в 10 раз.
«Пузомерку» не использую принципиально. Под нагрузкой не тестировал — т.к. мне и этих показателей хватило. Еще раз цитата из моего же коммента:
«Пузомерку» не использую принципиально. Под нагрузкой не тестировал — т.к. мне и этих показателей хватило. Еще раз цитата из моего же коммента:
Стрес-тест не устраивал, но думаю nginx (server side) просядет много хуже
Спасибо, что комментируете и критикуете! :)
Вот такой ответ на Ваш комментарий от инженеров команды PageSpeed (в моём перводе):
«Вполне возможно, что при большом количестве одновременных посетителей сайта или при синтетических тестах на пропускную способность HTML можно наблюдать снижение производительности. Но у большинства сайтов либо HTML генерируется динамически, либо они далеко не добирают до максимального уровня QPS (query per second) на статические файлы, и большинство запросов идущих на сервер идут на кэшируемые ресурсы, с которыми PageSpeed неплохо справляется.
В любом случае Nginx следует «покрывать» varnish, как описано в developers.google.com/speed/pagespeed/module/downstream-caching»
Вот такой ответ на Ваш комментарий от инженеров команды PageSpeed (в моём перводе):
«Вполне возможно, что при большом количестве одновременных посетителей сайта или при синтетических тестах на пропускную способность HTML можно наблюдать снижение производительности. Но у большинства сайтов либо HTML генерируется динамически, либо они далеко не добирают до максимального уровня QPS (query per second) на статические файлы, и большинство запросов идущих на сервер идут на кэшируемые ресурсы, с которыми PageSpeed неплохо справляется.
В любом случае Nginx следует «покрывать» varnish, как описано в developers.google.com/speed/pagespeed/module/downstream-caching»
Кроме того в это время также входит и время передачи ответа клиенту, которое зависит более от самого клиента, чем от nginx.Не зависит там ничего: клиент — тоже асинхронный сишный дамми-скрипт на N воркеров, паралельно забирающих URL из списка, гигабит (один на один на свиче), без валидации, без аутенификации, совсем без ничего (даже в чистую дроп пробовал).
Тогда так и напишите в посте. А то если Page Speed Score был 50 а стал 75, то не на 25%, а на 50% скорость увеличилась.
Я так и написал, что на моем примере рейтинг стал выше на 25%.
В таком случае все ясно. А то комментарий выше ввел в заблуждение.
Для тех, кто вдруг не хочет компилить и собирать это руками, делаем бэкап, добавляем в репу dotdeb, обновляемся, устанавливаем nginx-extras (там кроме всего прочего pagespeed), и начинаем от пункта «Настройка» из статьи.
Кстати у меня прирост был только на 2.5процента попугая — просто я тот еще оптимизатор (ну очень дотошный) и видимо все где можно уже поправил руками.
Кстати у меня прирост был только на 2.5
Считаю правильней делать pagespeed «руками». Инструкций — океаны и моря. У тех же Google и Yahoo.
Sign up to leave a comment.
Установка модуля pagespeed для Nginx на Debian 6