- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Умник. С начала хочу увидеть, как число max_clients связано с числом тредов апача. Там это написано. Давай, дерзай. Хочу чтобы ты сам что-то понял, прежде чем не разобравшись утверждать. Ты ж даже не извинишься, когда поймёшь.
пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача. Соответственно, если поставить MaxClients = 10, то одновременно он сможет обслуживать 10 соединений. Остальные клиенты будут ждать пока эти соединения обслужаться. Ни о какой "туевой хуче" речь не идет.
Кто будет извиняться?
И как это относится к тому, что умеет, а что не умеет апач в днный момент? Мне начать рассказывать, чего джинкс не умеет? )
да при том, что nginx легко обходит апач по производительности и по потребляемым ресурсам при отдаче статики на больших нагрузках. а в остальном ни при чем, да.
Тот, кто работает с Highload не по "мануалам из интернета" вполне это делает.
я шесть лет назад написал хттп-прокси, который держит 8К активных соединений. к сожалению, была выбрана по независящим от меня причинам модель как в апаче. до сих пор имею удовольствие наблюдать сколько времени проц. тратит впустую на переключение контекста.
я с проблемой 10К connections знаком изнутри, а не на уровне "поменяй в конфиге", так что поосторожнее с "мануалами из интернета", ок?
пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача.
Максимальному количеству потоков оно никогда равно небыло. Я не знаю, что такое нитка в данном контексте. Нитками я шью. Так вот два процесса апача могут обслуживать к примеру, 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
Один контролирующий процесс (родитель) запускает дочерние процессы. Каждый дочерний процесс создаёт внутри себя фиксированное число потоков как указано в соответствующей директиве так же, как и слушающий поток, который слушает подулючения и передаёт их в поток для ообработки, когда они поступают.
Ну и найдите 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.
Boris A Dolgov, Ну чтож. Давайте на выходных займёмся.
Raistlin добавил 11.10.2011 в 23:42
что нить и процесс не так уж и отличаются
т.е. нить = поток? Угу. Мало отличаются только переключением контекста. На переключение контекста тратится много ресурсов? =).
Максимальному количеству потоков оно никогда равно небыло. Я не знаю, что такое нитка в данном контексте. Нитками я шью. Так вот два процесса апача могут обслуживать к примеру, 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.
Ну и найдите 10 отличий...
суть, как отметил товарищ выше, в том, что в апаче применяются блокирующие сокеты, т.е. одно соединение требует одну нитку (поток). В 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 на все соединения.
Raistlin, что за мания величия в топике?
Предлагаю конкурс. Вы делаете связку apache_worker+php-fcgi (или что Вам угодно, но без apache_worker+mod_php, т.к. далеко не весь php тредобезопасен), я делаю связку nginx+php-fpm. Две одинаковые виртуалки на KVM могу выделить. Мы натравливаем на них siege и смотрим, у кого лучше показатели.
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 - вуаля. Мы в равных условиях.
Boris, я в пхп не очень разбираюсь, но вроде бы он не асинхронный? если не асинхронный, то все преимущество nginx банально пожрется выполнением пхп-кода, который будет опять же требовать нитку на себя. или я ошибаюсь?
Это правда. Но если скрипт относительно лёгкий (типичный пример из жизни -- анонсер торрент-трекера), то модульность apache и переключение нитей по 10 раз для чтения/записи данных туда-сюда могут съесть, думаю, около 25% используемых ресурсов против 5% от nginx.
Вот если сравнивать Perl-FastCGI vs Nginx + Apache vs пёрл в любом проявлении - тогда апач нервно курит в сторонке. А применительно к раздаче статики (которая в общем-то раздаётся очень эффективно и апачем) - здесь шансы почти уравниваются. Добавляем php - вуаля. Мы в равных условиях.
Тут как раз не факт -- т.к. apache+mod_perl почти не будет иметь накладных расходов на обмен данными между perl и вебсервером. Но это уже сложный вопрос, который нужно бенчмаркить.