Вернуться   Форум об интернет-маркетинге > >
Ответ
 
Опции темы
Старый 11.10.2011, 20:25   #41
Raistlin
Одинокий зверь
 
Аватар для Raistlin
 
Регистрация: 01.02.2010
Сообщений: 4,321
Репутация: 80337
Отправить сообщение для Raistlin с помощью ICQ Отправить сообщение для Raistlin с помощью Skype™
Социальные сети

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от iopiop Посмотреть сообщение
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.
Умник. С начала хочу увидеть, как число max_clients связано с числом тредов апача. Там это написано. Давай, дерзай. Хочу чтобы ты сам что-то понял, прежде чем не разобравшись утверждать. Ты ж даже не извинишься, когда поймёшь.

Цитата:
Сообщение от iopiop Посмотреть сообщение
для асинхронной модели только в апреле код закомитили.
И как это относится к тому, что умеет, а что не умеет апач в днный момент? Мне начать рассказывать, чего джинкс не умеет? )

Цитата:
Сообщение от iopiop Посмотреть сообщение
так только тот, кто столкнется с проблемой отсылки больших файлов из пхп.
Тот, кто работает с Highload не по "мануалам из интернета" вполне это делает.
Raistlin вне форума   Ответить с цитированием

Реклама
Старый 11.10.2011, 21:33   #42
iopiop
Кандидат наук
 
Регистрация: 24.12.2010
Сообщений: 254
Репутация: 31232

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от Raistlin Посмотреть сообщение
Умник. С начала хочу увидеть, как число max_clients связано с числом тредов апача. Там это написано. Давай, дерзай. Хочу чтобы ты сам что-то понял, прежде чем не разобравшись утверждать. Ты ж даже не извинишься, когда поймёшь.
пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача. Соответственно, если поставить MaxClients = 10, то одновременно он сможет обслуживать 10 соединений. Остальные клиенты будут ждать пока эти соединения обслужаться. Ни о какой "туевой хуче" речь не идет.

Кто будет извиняться?
Цитата:
Сообщение от Raistlin Посмотреть сообщение
И как это относится к тому, что умеет, а что не умеет апач в днный момент? Мне начать рассказывать, чего джинкс не умеет? )
да при том, что nginx легко обходит апач по производительности и по потребляемым ресурсам при отдаче статики на больших нагрузках. а в остальном ни при чем, да.
Цитата:
Сообщение от Raistlin Посмотреть сообщение
Тот, кто работает с Highload не по "мануалам из интернета" вполне это делает.
я шесть лет назад написал хттп-прокси, который держит 8К активных соединений. к сожалению, была выбрана по независящим от меня причинам модель как в апаче. до сих пор имею удовольствие наблюдать сколько времени проц. тратит впустую на переключение контекста.
я с проблемой 10К connections знаком изнутри, а не на уровне "поменяй в конфиге", так что поосторожнее с "мануалами из интернета", ок?
iopiop вне форума   Ответить с цитированием
Старый 11.10.2011, 22:39   #43
Raistlin
Одинокий зверь
 
Аватар для Raistlin
 
Регистрация: 01.02.2010
Сообщений: 4,321
Репутация: 80337
Отправить сообщение для Raistlin с помощью ICQ Отправить сообщение для Raistlin с помощью Skype™
Социальные сети

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от iopiop Посмотреть сообщение
пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача.
Максимальному количеству потоков оно никогда равно небыло. Я не знаю, что такое нитка в данном контексте. Нитками я шью. Так вот два процесса апача могут обслуживать к примеру, 40 потоков данных.

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

Цитата:
Архитектурно Nginx — это асинхронный сервер, который использует один главный процесс для приема соединений и несколько рабочих процессов для их обработки.

Теперь апач...
Цитата:
A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a server thread for processing when they arrive.
Перевод:
Один контролирующий процесс (родитель) запускает дочерние процессы. Каждый дочерний процесс создаёт внутри себя фиксированное число потоков как указано в соответствующей директиве так же, как и слушающий поток, который слушает подулючения и передаёт их в поток для ообработки, когда они поступают.

Ну и найдите 10 отличий...
Raistlin вне форума   Ответить с цитированием
Старый 11.10.2011, 22:42   #44
Boris A Dolgov
Академик
 
Аватар для Boris A Dolgov
 
Регистрация: 04.07.2007
Адрес: ISPlicense.ru
Сообщений: 2,599
Репутация: 129039
Отправить сообщение для Boris A Dolgov с помощью Skype™
Социальные сети Профиль на Хабрахабре

По умолчанию Re: Nginx - парадокс

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

Boris A Dolgov добавил 11.10.2011 в 22:43
Цитата:
Сообщение от Raistlin Посмотреть сообщение
Один контролирующий процесс (родитель) запускает дочерние процессы. Каждый дочерний процесс создаёт внутри себя фиксированное число потоков как указано в соответствующей директиве так же, как и слушающий поток, который слушает подулючения и передаёт их в поток для ообработки, когда они поступают.

Ну и найдите 10 отличий...
Вы не отличаете понятие "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.
__________________
С уважением, Борис Долгов.
Администрирование, дешевые лицензии ISPsystem, Parallels, cPanel, DirectAdmin, скины, SSL - ISPlicense.ru

Последний раз редактировалось Boris A Dolgov; 11.10.2011 в 23:24.. Причина: Добавлено сообщение
Boris A Dolgov вне форума   Ответить с цитированием
Старый 11.10.2011, 23:40   #45
Raistlin
Одинокий зверь
 
Аватар для Raistlin
 
Регистрация: 01.02.2010
Сообщений: 4,321
Репутация: 80337
Отправить сообщение для Raistlin с помощью ICQ Отправить сообщение для Raistlin с помощью Skype™
Социальные сети

По умолчанию Re: Nginx - парадокс

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

Raistlin добавил 11.10.2011 в 23:42
Цитата:
Сообщение от Boris A Dolgov Посмотреть сообщение
что нить и процесс не так уж и отличаются
т.е. нить = поток? Угу. Мало отличаются только переключением контекста. На переключение контекста тратится много ресурсов? =).

Последний раз редактировалось Raistlin; 11.10.2011 в 23:42.. Причина: Добавлено сообщение
Raistlin вне форума   Ответить с цитированием
Старый 11.10.2011, 23:43   #46
iopiop
Кандидат наук
 
Регистрация: 24.12.2010
Сообщений: 254
Репутация: 31232

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от Raistlin Посмотреть сообщение
Максимальному количеству потоков оно никогда равно небыло. Я не знаю, что такое нитка в данном контексте. Нитками я шью. Так вот два процесса апача могут обслуживать к примеру, 40 потоков данных.
повторяем в четвертый раз (уже как мантра):

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.

Цитата:
Сообщение от Raistlin Посмотреть сообщение
Ну и найдите 10 отличий...
суть, как отметил товарищ выше, в том, что в апаче применяются блокирующие сокеты, т.е. одно соединение требует одну нитку (поток). В ngnix используются неблокирующие сокеты, поэтому количество соединений на одну нитку (поток) определяется на самом деле только количеством памяти, которое ОС может выделить под буферы + накладные расходны одной нитки (потока).
Поэтому рекомендуемое количество ниток (потоков) в nginx равно количеству ядер процессора + 1 - больше не имеет смысла. А в апаче количество ниток (потоков) приходится выставлять сотнями, чтобы обслужить все соединения.

iopiop добавил 11.10.2011 в 23:51
Цитата:
Сообщение от Raistlin Посмотреть сообщение
т.е. нить = поток? Угу. Мало отличаются только переключением контекста. На переключение контекста тратится много ресурсов? =).
на архитектуре WinNT только переход из user land в kernel требует порядка 800 тактов процессора. а это только малая часть. На линуксе к сожалению точными цифрами не владею.
Но в любом случае, когда у вас 10К ниток (потоков) - накладные расходы очень велики, для каждой нитки (потока) сохранить содержимое регистров процессора, сохранить стек - а он у каждой нитки (потока) свой, в кеш проца это все не влазит, значит все падает в память, да еще и планировщик должен перекидывать нитки (потоки) из одной очереди в другую по хитрому алгоритму, пытаясь угодить всем 10К ниткам (потокам).
это как с комарами, один комар - не страшно, а вот когда 10К комаров....

Последний раз редактировалось iopiop; 11.10.2011 в 23:54.. Причина: Добавлено сообщение
iopiop вне форума   Ответить с цитированием
Старый 11.10.2011, 23:59   #47
Boris A Dolgov
Академик
 
Аватар для Boris A Dolgov
 
Регистрация: 04.07.2007
Адрес: ISPlicense.ru
Сообщений: 2,599
Репутация: 129039
Отправить сообщение для Boris A Dolgov с помощью Skype™
Социальные сети Профиль на Хабрахабре

По умолчанию Re: Nginx - парадокс

Цитата:
т.е. нить = поток? Угу. Мало отличаются только переключением контекста. На переключение контекста тратится много ресурсов? =).
Если говорить языком операционной системы, 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 A Dolgov вне форума   Ответить с цитированием
Старый 12.10.2011, 00:01   #48
iopiop
Кандидат наук
 
Регистрация: 24.12.2010
Сообщений: 254
Репутация: 31232

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от Boris A Dolgov Посмотреть сообщение
Raistlin, что за мания величия в топике?
Предлагаю конкурс. Вы делаете связку apache_worker+php-fcgi (или что Вам угодно, но без apache_worker+mod_php, т.к. далеко не весь php тредобезопасен), я делаю связку nginx+php-fpm. Две одинаковые виртуалки на KVM могу выделить. Мы натравливаем на них siege и смотрим, у кого лучше показатели.
Boris, я в пхп не очень разбираюсь, но вроде бы он не асинхронный? если не асинхронный, то все преимущество nginx банально пожрется выполнением пхп-кода, который будет опять же требовать нитку на себя. или я ошибаюсь?
iopiop вне форума   Ответить с цитированием
Старый 12.10.2011, 00:12   #49
Raistlin
Одинокий зверь
 
Аватар для Raistlin
 
Регистрация: 01.02.2010
Сообщений: 4,321
Репутация: 80337
Отправить сообщение для Raistlin с помощью ICQ Отправить сообщение для Raistlin с помощью Skype™
Социальные сети

По умолчанию Re: Nginx - парадокс

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

Вот если сравнивать Perl-FastCGI vs Nginx + Apache vs пёрл в любом проявлении - тогда апач нервно курит в сторонке. А применительно к раздаче статики (которая в общем-то раздаётся очень эффективно и апачем) - здесь шансы почти уравниваются. Добавляем php - вуаля. Мы в равных условиях.
Raistlin вне форума   Ответить с цитированием
Старый 12.10.2011, 00:12   #50
Boris A Dolgov
Академик
 
Аватар для Boris A Dolgov
 
Регистрация: 04.07.2007
Адрес: ISPlicense.ru
Сообщений: 2,599
Репутация: 129039
Отправить сообщение для Boris A Dolgov с помощью Skype™
Социальные сети Профиль на Хабрахабре

По умолчанию Re: Nginx - парадокс

Цитата:
Сообщение от iopiop Посмотреть сообщение
Boris, я в пхп не очень разбираюсь, но вроде бы он не асинхронный? если не асинхронный, то все преимущество nginx банально пожрется выполнением пхп-кода, который будет опять же требовать нитку на себя. или я ошибаюсь?
Это правда. Но если скрипт относительно лёгкий (типичный пример из жизни -- анонсер торрент-трекера), то модульность apache и переключение нитей по 10 раз для чтения/записи данных туда-сюда могут съесть, думаю, около 25% используемых ресурсов против 5% от nginx.
Boris A Dolgov вне форума   Ответить с цитированием
Ответ



Опции темы

Быстрый переход


Регистрация Справка Календарь Поддержка Все разделы прочитаны