Comments 43
Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.
Количество процессов nginx при работе с nginx должно быть равно или больше количества ядер процессора.
Интересно, а раньше вы сколько процессов запускали? Один? Я всегда выставлял количество форков равным количеству ядер. Правда обычно узким местом становится дисковая подсистема или канал, а никак не энджи.
+11
Ну, если nginx работает чисто как прокси (и как оказалось без сжатия), то 1 процесса более чем достаточно, и память лишнюю не тратим…
0
Уж что-что, а память энджи кушает ооочень аккуратно, так что пару лишних форков вы не заметите даже на vds эконом-класса. Зато, по возможности, операции будут параллелиться.
+8
Я в принципе с вами согласен, но есть есть 2 момента:
1) Бритва Оккама («Не следует множить сущее без необходимости»). Сейчас необходимость уже видна :-)
2) Лишние переключения контекста
1) Бритва Оккама («Не следует множить сущее без необходимости»). Сейчас необходимость уже видна :-)
2) Лишние переключения контекста
0
Ну и насчет памяти — «100 бабушек — рубль» ;-)
Я не потрачу лишние 2*7 метров, если не понятно, зачем я это делаю.
В том то и дело, что nginx способен параллелить практически все что нужно и в одном процессе, в том числе уже и IO (через aio).
А про gzip я и предположить не мог…
Я не потрачу лишние 2*7 метров, если не понятно, зачем я это делаю.
В том то и дело, что nginx способен параллелить практически все что нужно и в одном процессе, в том числе уже и IO (через aio).
А про gzip я и предположить не мог…
0
> энджи
Как только nginx не называют…
Как только nginx не называют…
+3
«энджи»… — это прямо уже с такой скупой сисадминской нежностью и заботой :-)
+5
engine звучит в транскрипции именно так: ['enʤɪn], «энджи» — это сокращенный, разговорный вариант.
+2
Я не понимаю как «engine x» превратился в «энджи».
-1
Всю жизнь думал, что это «энгинкс», а оказалось «engine x»!
+2
прочтите по транскрипции слово engine (hint: «э'нджин»), затем отбросьте последнюю букву.
+1
hint: не надо отбрасывать последнюю букву, это часть названия
hint#2: «nginx» и есть транскрипция.
hint#2: «nginx» и есть транскрипция.
-2
вы все слова всегда произносите целиком?
#2: Транскрипция — это запись звучания слова, подразумевающая однозначное прочтение/произношение. У каждой из этих букв есть несколько вариантов звучания, оттуда и растут всяческие «нгинкс»ы. Кроме того, я просто отвечал на ваш вопрос:
#2: Транскрипция — это запись звучания слова, подразумевающая однозначное прочтение/произношение. У каждой из этих букв есть несколько вариантов звучания, оттуда и растут всяческие «нгинкс»ы. Кроме того, я просто отвечал на ваш вопрос:
Я не понимаю как «engine x» превратился в «энджи»., я вам пояснил эволюцию процесса, вы же ударились, простите, в занудство, потянув и меня туда.
0
engine просто не «энджайн» читается, как думает поразительно большое количество людей :)
0
UFO just landed and posted this here
>> и ложим в том же каталоге с расширением.
покладаем блин.
покладаем блин.
+10
Просьба в следующий раз на графиках подписывать что отложено по осям — краткое описание и единицы измерения. Искать эту информацию в тексте крайне неудобно.
+12
ngx_http_gzip_static_module — замечательная вещь.
Падение времени отдачи страницы (график из google webmaster tools) — результат упаковки css и js файлов и размещение их на ssd-носителе
Падение времени отдачи страницы (график из google webmaster tools) — результат упаковки css и js файлов и размещение их на ssd-носителе
+3
ничего себе…
такой прирост производительности только от упаковки css и js?
такой прирост производительности только от упаковки css и js?
+1
Webmaster tools такую чушь показывает иногда, что я на него уже не смотрю…
+8
Ну, js-кода было довольно много (jquery + несколько плагинов), да и перенос на SSD повлиял (ибо пользуюсь VDS, а там соседи тоже хотят обращаться к диску)
+1
С падением RPS с 370 до 100 при сжатии 9 на самом деле можно мириться если у вас отдается не статика. Там время генерации один фиг не даст отдать 370 страниц в секунду.
Хотя согласен что 5 выглядит оптимальным вариантом по соотношению сжатие/RPS.
Хотя согласен что 5 выглядит оптимальным вариантом по соотношению сжатие/RPS.
+1
370 — легко, если это конечно не монстроидальная CMS ;-)
А уж 200 можно и на хомячке на дешевом VPS. :-)
А уж 200 можно и на хомячке на дешевом VPS. :-)
0
Уважаемый автор, расскажите, как вы замеряли всякие параметры типа скорости отдачи, запросы в секунду, и все такое прочее. Какие инструменты использоватли. Спасибо.
+2
Проверили тогда бы еще и js + css на примере каких-дь фреймворков.
По идее не должно сильно отличаться… ну а вдруг?
По идее не должно сильно отличаться… ну а вдруг?
+1
Все это жмется более-менее одинаково, и серьёзный отличий нет…
Хотя конечно minified-js жмется хуже :-)
Хотя конечно minified-js жмется хуже :-)
0
CSS/JS жмутся статикой, тестировать на них производительность сжатия на лету смысла нет
0
Жмутся статикой если настроить :-)
Я ни разу не видел сервера с настроенной статикой :-)
Я ни разу не видел сервера с настроенной статикой :-)
0
я тоже, поэтому WEBO Site SpeedUp автоматом сам все делает
0
а в nginx'е deflate не поддерживается? он же вроде раза в два быстрее при той же степени сжатия (если верить интернетам)
+1
Действительно, deflate лучше и по скорости и по сжатию… Напрямую поддержки в nginx пока не заметил, жесть…
0
Про то почему gzip а не deflate у игоря написано sysoev.ru/mod_deflate/readme.html#mehtods
0
Sign up to leave a comment.
GZip и nginx: влияние на производительность