Nginx - парадокс

пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача. Соответственно, если поставить MaxClients = 10, то одновременно он сможет обслуживать 10 соединений. Остальные клиенты будут ждать пока эти соединения обслужаться. Ни о какой "туевой хуче" речь не идет.

Кто будет извиняться?

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

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

я с проблемой 10К connections знаком изнутри, а не на уровне "поменяй в конфиге", так что поосторожнее с "мануалами из интернета", ок?

Максимальному количеству потоков оно никогда равно небыло. Я не знаю, что такое нитка в данном контексте. Нитками я шью. Так вот два процесса апача могут обслуживать к примеру, 40 потоков данных.

Nginx работает подобным образом. Если быть точным, то вот так:

Теперь апач...

Перевод:

Один контролирующий процесс (родитель) запускает дочерние процессы. Каждый дочерний процесс создаёт внутри себя фиксированное число потоков как указано в соответствующей директиве так же, как и слушающий поток, который слушает подулючения и передаёт их в поток для ообработки, когда они поступают.

Ну и найдите 10 отличий...

Raistlin, что за мания величия в топике?

Предлагаю конкурс. Вы делаете связку apache_worker+php-fcgi (или что Вам угодно, но без apache_worker+mod_php, т.к. далеко не весь php тредобезопасен), я делаю связку nginx+php-fpm. Две одинаковые виртуалки на KVM могу выделить. Мы натравливаем на них siege и смотрим, у кого лучше показатели. Правда заняться смогу только через пару дней.

Boris A Dolgov добавил 11.10.2011 в 22:43

Вы не отличаете понятие "1 process with n threads per n connections "1 process with 1 thread per 100k connections"? Тогда Вам в man 7 pthreads как минимум, чтобы понять, что нить и процесс не так уж и отличаются, потом в man 2 select или в man 2 poll для понимания того, что такое событийная система, и потом в man 7 epoll или man 2 kqueue (в зависимости от платформы) для полного понимания её глубин.

Ещё можете заглянуть в man 2 clone, если Ваша ОС его поддерживает. На ней же можете заглянуть в /proc/что-нибудь/task.

Boris A Dolgov, Ну чтож. Давайте на выходных займёмся.

Raistlin добавил 11.10.2011 в 23:42

т.е. нить = поток? Угу. Мало отличаются только переключением контекста. На переключение контекста тратится много ресурсов? =).

повторяем в четвертый раз (уже как мантра):

The maximum number of clients that may be served simultaneously (i.e., the maximum total number of threads in all processes) is determined by the MaxClients directive.

threads - это, по-вашему, потоки. в вашем примере MaxClient = 40. и все, остальные соединения будут ждать пока эти отработают.

домашнее задание - выставьте MaxClient=2 попробуйте открыть страничку какую-нибудь с кучей картинок, посмотрите как долго она будет открываться. для большего счастья выставьте Keep-Alive = 60.

суть, как отметил товарищ выше, в том, что в апаче применяются блокирующие сокеты, т.е. одно соединение требует одну нитку (поток). В ngnix используются неблокирующие сокеты, поэтому количество соединений на одну нитку (поток) определяется на самом деле только количеством памяти, которое ОС может выделить под буферы + накладные расходны одной нитки (потока).

Поэтому рекомендуемое количество ниток (потоков) в nginx равно количеству ядер процессора + 1 - больше не имеет смысла. А в апаче количество ниток (потоков) приходится выставлять сотнями, чтобы обслужить все соединения.

iopiop добавил 11.10.2011 в 23:51

на архитектуре WinNT только переход из user land в kernel требует порядка 800 тактов процессора. а это только малая часть. На линуксе к сожалению точными цифрами не владею.

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

это как с комарами, один комар - не страшно, а вот когда 10К комаров....

Если говорить языком операционной системы, thread = нить = поток, process = процесс. C точки зрения планировщика и переключения контестов (по крайней мере с очень маленькой погрешностью в linux и freebsd (так как не изменяется paging table)) thread = process, что делает переключение thread очень похожим по тяжести с переключением process. Но создание у thread намного проще чем у process, так как не нужно копировать кучу данных (не нужно говорить про cow, я говорю о структурах в ядре).

С точки зрения вебсервера можно говорить, что thread -- это нечто, имеющее свой стек и возможность блокироваться на системном вызове. Тогда process в некотором смысле тоже является thread. Тогда mpm_prefork и mpm с threads не сильно отличаются, так как требуют thread на соединение.

event-модель же требует наличия всего лишь одного thread на все соединения.

Boris, я в пхп не очень разбираюсь, но вроде бы он не асинхронный? если не асинхронный, то все преимущество nginx банально пожрется выполнением пхп-кода, который будет опять же требовать нитку на себя. или я ошибаюсь?

iopiop, не ошибаетесь. Я то говорю об условиях реального хостинга. Т.е. php-fpm оно, конечно, круто, но php фактически не ускоряется при использовании fastcgi или fpm (точнее, очень не значительно). fastcgi используют в основном для того, чтобы заработали такие вещи как eAccelerator. С php-cgi использование акселеряторов вообще, мягко говоря, мало реально. С mod_php стабильно получается работать только у php-apc. т.е. у апача в режиме воркера есть одна проблемка: PHP можно акселерировать только на fastcgi.

Вот если сравнивать Perl-FastCGI vs Nginx + Apache vs пёрл в любом проявлении - тогда апач нервно курит в сторонке. А применительно к раздаче статики (которая в общем-то раздаётся очень эффективно и апачем) - здесь шансы почти уравниваются. Добавляем php - вуаля. Мы в равных условиях.

Это правда. Но если скрипт относительно лёгкий (типичный пример из жизни -- анонсер торрент-трекера), то модульность apache и переключение нитей по 10 раз для чтения/записи данных туда-сюда могут съесть, думаю, около 25% используемых ресурсов против 5% от nginx.

Тут как раз не факт -- т.к. apache+mod_perl почти не будет иметь накладных расходов на обмен данными между perl и вебсервером. Но это уже сложный вопрос, который нужно бенчмаркить.