Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.
Количество процессов nginx при работе с nginx должно быть равно или больше количества ядер процессора.
Интересно, а раньше вы сколько процессов запускали? Один? Я всегда выставлял количество форков равным количеству ядер. Правда обычно узким местом становится дисковая подсистема или канал, а никак не энджи.
Ну, если nginx работает чисто как прокси (и как оказалось без сжатия), то 1 процесса более чем достаточно, и память лишнюю не тратим…
Уж что-что, а память энджи кушает ооочень аккуратно, так что пару лишних форков вы не заметите даже на vds эконом-класса. Зато, по возможности, операции будут параллелиться.
Я в принципе с вами согласен, но есть есть 2 момента:
1) Бритва Оккама («Не следует множить сущее без необходимости»). Сейчас необходимость уже видна :-)
2) Лишние переключения контекста
1) Бритва Оккама («Не следует множить сущее без необходимости»). Сейчас необходимость уже видна :-)
2) Лишние переключения контекста
Ну и насчет памяти — «100 бабушек — рубль» ;-)
Я не потрачу лишние 2*7 метров, если не понятно, зачем я это делаю.
В том то и дело, что nginx способен параллелить практически все что нужно и в одном процессе, в том числе уже и IO (через aio).
А про gzip я и предположить не мог…
Я не потрачу лишние 2*7 метров, если не понятно, зачем я это делаю.
В том то и дело, что nginx способен параллелить практически все что нужно и в одном процессе, в том числе уже и IO (через aio).
А про gzip я и предположить не мог…
> энджи
Как только nginx не называют…
Как только nginx не называют…
«энджи»… — это прямо уже с такой скупой сисадминской нежностью и заботой :-)
engine звучит в транскрипции именно так: ['enʤɪn], «энджи» — это сокращенный, разговорный вариант.
Я не понимаю как «engine x» превратился в «энджи».
Всю жизнь думал, что это «энгинкс», а оказалось «engine x»!
прочтите по транскрипции слово engine (hint: «э'нджин»), затем отбросьте последнюю букву.
hint: не надо отбрасывать последнюю букву, это часть названия
hint#2: «nginx» и есть транскрипция.
hint#2: «nginx» и есть транскрипция.
вы все слова всегда произносите целиком?
#2: Транскрипция — это запись звучания слова, подразумевающая однозначное прочтение/произношение. У каждой из этих букв есть несколько вариантов звучания, оттуда и растут всяческие «нгинкс»ы. Кроме того, я просто отвечал на ваш вопрос:
#2: Транскрипция — это запись звучания слова, подразумевающая однозначное прочтение/произношение. У каждой из этих букв есть несколько вариантов звучания, оттуда и растут всяческие «нгинкс»ы. Кроме того, я просто отвечал на ваш вопрос:
Я не понимаю как «engine x» превратился в «энджи»., я вам пояснил эволюцию процесса, вы же ударились, простите, в занудство, потянув и меня туда.
engine просто не «энджайн» читается, как думает поразительно большое количество людей :)
>> и ложим в том же каталоге с расширением.
покладаем блин.
покладаем блин.
Просьба в следующий раз на графиках подписывать что отложено по осям — краткое описание и единицы измерения. Искать эту информацию в тексте крайне неудобно.
ngx_http_gzip_static_module — замечательная вещь.
Падение времени отдачи страницы (график из google webmaster tools) — результат упаковки css и js файлов и размещение их на ssd-носителе
Падение времени отдачи страницы (график из google webmaster tools) — результат упаковки css и js файлов и размещение их на ssd-носителе
ничего себе…
такой прирост производительности только от упаковки css и js?
такой прирост производительности только от упаковки css и js?
С падением RPS с 370 до 100 при сжатии 9 на самом деле можно мириться если у вас отдается не статика. Там время генерации один фиг не даст отдать 370 страниц в секунду.
Хотя согласен что 5 выглядит оптимальным вариантом по соотношению сжатие/RPS.
Хотя согласен что 5 выглядит оптимальным вариантом по соотношению сжатие/RPS.
Уважаемый автор, расскажите, как вы замеряли всякие параметры типа скорости отдачи, запросы в секунду, и все такое прочее. Какие инструменты использоватли. Спасибо.
Проверили тогда бы еще и js + css на примере каких-дь фреймворков.
По идее не должно сильно отличаться… ну а вдруг?
По идее не должно сильно отличаться… ну а вдруг?
Все это жмется более-менее одинаково, и серьёзный отличий нет…
Хотя конечно minified-js жмется хуже :-)
Хотя конечно minified-js жмется хуже :-)
CSS/JS жмутся статикой, тестировать на них производительность сжатия на лету смысла нет
Жмутся статикой если настроить :-)
Я ни разу не видел сервера с настроенной статикой :-)
Я ни разу не видел сервера с настроенной статикой :-)
я тоже, поэтому WEBO Site SpeedUp автоматом сам все делает
а в nginx'е deflate не поддерживается? он же вроде раза в два быстрее при той же степени сжатия (если верить интернетам)
Действительно, deflate лучше и по скорости и по сжатию… Напрямую поддержки в nginx пока не заметил, жесть…
Про то почему gzip а не deflate у игоря написано sysoev.ru/mod_deflate/readme.html#mehtods
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GZip и nginx: влияние на производительность