отказаться от apache, есть ли смысл?

До чего приятно следить, как гребет старый лодочник, - особенно если он нанят по часам. Какое восхитительное спокойствие, какая умиротворенность в каждом его движении! Ни малейшего намека на суетливую поспешность, на лихорадочное стремление вперед, которое становится сущим проклятием девятнадцатого века. Старый лодочник никогда не утруждает себя попытками обогнать другие лодки. Он нисколько не тревожится, когда какая-нибудь из них обгоняет его, - собственно говоря, они все его обгоняют, если только плывут в ту же сторону. Есть люди, которых это раздражает и выводит из себя; великолепная невозмутимость наемного лодочника во время этого испытания может послужить нам прекрасным уроком и предостережением против честолюбия и гордыни.

Неправда. Я Вам объяснял уже, что неактивные KeepAlive соединения - обслуживаются в одном потоке.

Допускаю, конечно, что nginx для хранения данных этих соединений использует какой-то шибко эффективный в отношении памяти мегаформат. Но профит явно будет не в разы и даже не с существенным коэффициентом.

Ага... Т.е. все-таки - дело-то не в памяти.

Кстати, недостатки этой модели тоже "очевидны". Один из них Вы уже приводили.

проще прикинуть хотя бы расходы памяти. они сокращаются до вышеназванных 2.5 мб на 10000 + фиксированной объем на одного worker. И больше никаких расходов нет.

Посчитать эффект от принципиального несоздания потоков по сравнению с их созданием и поддержкой сложно. Но он точно есть.

В промежутках между состояниями keep-alive, фронтенд не может быстро отправить ответ клиенту и освободиться. Все время отправки файла поток в апаче занимает и память и ресурсы ОС. Потоков много и CPU постоянно занимается переключением контекстов. mpm_event устраняет только лишь фазу keep-alive ожидания потоком клиента.

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

Сокращаются _от чего_? Напоминаю, в апаче тут тоже только один поток.

Переключение контекста. "Созданием" потоков апач занимается только тогда, когда сконфигурирован неправильно, или нагрузка резко подскочила.

Согласен, хотя думаю что в отношении памяти Вы погорячились. Расход памяти на служебную информацию для создания потока - действительно может быть порядка той, что затрачивается на обработку запроса?

netwind, здравствуйте. Есть ли статьи, публикации по внутренней работе nginx? Или вы все почерпнули из исходный кодов?

Если несколько соединений будет с одним и тем же состоянием, то nginx их будкт обрабатывать в последовательном порядке? Правильно ли я понимаю, что в случае с большим io_wait зависает вся "цепочка" таких соединений?

нет речь шла о общем расходе памяти. все потоки apache против всех потоков nginx (из которых спокойно можно оставить один ). активные потоки имеют свои локальные переменные и их в сервере общего назначения много.

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

Если потоков много, а ядер процессоров мало, переключение контекстов обязательно возникает. Чем больше потоков тем более выражены негативные эффекты. Отсюда и советы сделать число воркеров nginx равное числу ядер.

Более того, переключение контекстов происходит каждый раз и при вызове фунций ОС. Эффективные приложения пытаются минимизировать и число вызовов ОС тоже. Например, пытаются запихнуть в один вызов максимально много данных. Тут очень к месту приходятся специальные вызовы ОС : select, epoll, фильтры httpready и т.д.

В апаче, как в сервере общего назначения для прикладных программистов, этого всего нет и не будет.

А в nginx, в свою очередь, никогда не возникнет mod_php.

Это все стандартная модель работы серверов описанная в литературе. Не обязательно читать код nginx, чтобы понимать как и почему он эффективно работает. Так же работают lighttpd, squid, varnish и менее известные программы.

Да, в последовательном порядке. Однако, благодаря использованию неблокируемых функций ввода-вывода даже при больших io_wait потоки nginx не тормозятся.

И это не то, что называется AIO в nginx. Использование AIO еще больше сокращает необходимость в системных вызовах.

Использование sendfile вообще исключает переключение контекстов во время отправки файла по сети, так как ядро полностью берет на себя все связанные с отправкой функции.

Нееет, дядинька. Вы заявили только вот цифирь:

Не всех/не всегда, ЕМНИП.

Стандартная модель - вовсе не эта. Стандарт - это апач. А lighttpd, squid, varnish, nginx - как раз "менее известные программы".

Наверно, их назначение наводит на мысль об ограниченности подобной "стандартной модели"? Или то, что это раздавалки статики да прокси/кешеры - абсолютно случайное совпадение?

Ну а зачем nginx нужно больше для активных соединений ? Все остальное это буферы. Их размер скромный и конечный. А вот апач в данной ситуации понаплодит переменных во всех своих модулях просто потому что модули написаны для традиционной модели.

Тут "стандартный" не в смысле ограниченности некоторых программистов стандартами, а в том смысле, что эта модель не является изобретением Сысоева лично. Просто одна из известных моделей обработки, особенно выгодная при обслуживании большого числа сетевых соединений.

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

Да вы вон лучше какому-нибудь любимому клиенту фронтенд c nginx на апач смените и проверите на практике. Наверняка, такие найдутся.

Желательно проект побольше. С несколькими физическими бекендами.

Все-таки - поболее будет, чем для активных, не?

Разделяемая память? Этим, мягко говоря, пользуются. MPM очень активно делают независимыми и привязка модулей к конкретному - не приветствуется.

Просто обычно под "стандартным" - подразумевается что-то распространенное, популярная модель. Назвать таковой подход nginx - покуда сложно. Сколько там? - 8% на _нагруженных_ сайтах. А остальное - нешто IIS?

При каком? Что-то мне подсказывает, что в роли бакенда эта модель покуда редкость. Это случайно?

Работает - не трогай.

Но может и попробую как-нибудь - в тестах смотрится вполне нормально. Плюс, в Debian сейчас можно относительно удобно несколько копий апача запустить. Не нужно гемороя со сборкой пакета nginx, etc. И модулей под апач немало вкусных.

тут вообще ничего не понял.

хорошо, с терминологией определились.

Обсуждение началось с вашего заявления о равноценности mpm_event и nginx на фронтенде. Только это утверждение я оспариваю.

ну вот и подождем.