Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.
Количество процессов nginx при работе с nginx должно быть равно или больше количества ядер процессора.

Интересно, а раньше вы сколько процессов запускали? Один? Я всегда выставлял количество форков равным количеству ядер. Правда обычно узким местом становится дисковая подсистема или канал, а никак не энджи.
Ну, если nginx работает чисто как прокси (и как оказалось без сжатия), то 1 процесса более чем достаточно, и память лишнюю не тратим…
Уж что-что, а память энджи кушает ооочень аккуратно, так что пару лишних форков вы не заметите даже на vds эконом-класса. Зато, по возможности, операции будут параллелиться.
Я в принципе с вами согласен, но есть есть 2 момента:

1) Бритва Оккама («Не следует множить сущее без необходимости»). Сейчас необходимость уже видна :-)
2) Лишние переключения контекста
1) Правильное название — Принцип Экономии. )
2) Между где? Энджи да же при
worker_processes  1;
от мастер-процесса форкает рабочий процесс.
Ну да, форкает, мы же не можем с этим ничего сделать :-)
Ну и насчет памяти — «100 бабушек — рубль» ;-)
Я не потрачу лишние 2*7 метров, если не понятно, зачем я это делаю.

В том то и дело, что nginx способен параллелить практически все что нужно и в одном процессе, в том числе уже и IO (через aio).
А про gzip я и предположить не мог…
> энджи
Как только nginx не называют…
«энджи»… — это прямо уже с такой скупой сисадминской нежностью и заботой :-)
engine звучит в транскрипции именно так: ['enʤɪn], «энджи» — это сокращенный, разговорный вариант.
Я не понимаю как «engine x» превратился в «энджи».
Всю жизнь думал, что это «энгинкс», а оказалось «engine x»!
Слышал Сысоева живьем (на одном из РИТов), так он сказал: «Как только не говорят. Так как же его называть? Правильно ЭнджинИкс»
А до этого я и сам как только его не звал :)
ну если уж мы от английского пляшем, то энджинЭкс :)
М… В данном случае мы пляшем от мнения его автора :)
прочтите по транскрипции слово engine (hint: «э'нджин»), затем отбросьте последнюю букву.
hint: не надо отбрасывать последнюю букву, это часть названия
hint#2: «nginx» и есть транскрипция.
вы все слова всегда произносите целиком?
#2: Транскрипция — это запись звучания слова, подразумевающая однозначное прочтение/произношение. У каждой из этих букв есть несколько вариантов звучания, оттуда и растут всяческие «нгинкс»ы. Кроме того, я просто отвечал на ваш вопрос:
Я не понимаю как «engine x» превратился в «энджи».
, я вам пояснил эволюцию процесса, вы же ударились, простите, в занудство, потянув и меня туда.
engine просто не «энджайн» читается, как думает поразительно большое количество людей :)
НЛО прилетело и оставило эту надпись здесь.
а некоторые мои знакомые произносят «нгинкс» (дословно) и тоже всем понятно )
Но смешно до коликов. Если вдруг придется с иностранцами обсуждать эту тему? Мне приходилось. Произносить нужно максимально близко к оригиналу, а оригиналом является английское слово.
>> и ложим в том же каталоге с расширением.
покладаем блин.
Исправил. А комменты — уже навсегда. :-)
Просьба в следующий раз на графиках подписывать что отложено по осям — краткое описание и единицы измерения. Искать эту информацию в тексте крайне неудобно.
Хмм, действительно :-)
ngx_http_gzip_static_module — замечательная вещь.
Падение времени отдачи страницы (график из google webmaster tools) — результат упаковки css и js файлов и размещение их на ssd-носителе
ничего себе…
такой прирост производительности только от упаковки css и js?
Webmaster tools такую чушь показывает иногда, что я на него уже не смотрю…
что бы он не показывал, но на его показатели приходится ориентироваться
ибо гугл ранжирует сайт в том числе и по скорости отдачи контента
Ну, js-кода было довольно много (jquery + несколько плагинов), да и перенос на SSD повлиял (ибо пользуюсь VDS, а там соседи тоже хотят обращаться к диску)
С падением RPS с 370 до 100 при сжатии 9 на самом деле можно мириться если у вас отдается не статика. Там время генерации один фиг не даст отдать 370 страниц в секунду.
Хотя согласен что 5 выглядит оптимальным вариантом по соотношению сжатие/RPS.
370 — легко, если это конечно не монстроидальная CMS ;-)
А уж 200 можно и на хомячке на дешевом VPS. :-)
Достаточно монстроидального фреймворка, а на них сейчас почти все :).
Естественно если сайт написан с сильным упором на производительность можно и больше выжать, но крайне редкое явление. Обычно время генерации хотя бы несколько сотых, а не меньше 0.003 секунды
Уважаемый автор, расскажите, как вы замеряли всякие параметры типа скорости отдачи, запросы в секунду, и все такое прочее. Какие инструменты использоватли. Спасибо.
ab -c 10 -t 10 -H «Accept-Encoding: gzip,deflate» 127.0.0.1:81/2/test_big.html

Вот собственно и все :-)

/2/ в урле — это степень сжатия (чтобы не перегружать каждый раз), так настроен vhost nginx-а.
Проверили тогда бы еще и js + css на примере каких-дь фреймворков.
По идее не должно сильно отличаться… ну а вдруг?
Все это жмется более-менее одинаково, и серьёзный отличий нет…
Хотя конечно minified-js жмется хуже :-)
CSS/JS жмутся статикой, тестировать на них производительность сжатия на лету смысла нет
Жмутся статикой если настроить :-)
Я ни разу не видел сервера с настроенной статикой :-)
я тоже, поэтому WEBO Site SpeedUp автоматом сам все делает
а в nginx'е deflate не поддерживается? он же вроде раза в два быстрее при той же степени сжатия (если верить интернетам)
Действительно, deflate лучше и по скорости и по сжатию… Напрямую поддержки в nginx пока не заметил, жесть…
Про то почему gzip а не deflate у игоря написано sysoev.ru/mod_deflate/readme.html#mehtods
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.