http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/
как видно, апач просто падает при более 300(600) одновременных коннектов на порядка 10К запросов в секунду.
nginx держит порядка 22К запросов в секунду, при этом количество одновременных коннектов не важно.
вы погуглите "compare apache nginx", графиков подобных этому дофига и больше.
ну еще погуглите "C10K problem" чтобы понять в чем дело.
PS лично мне было бы стыдно указывать в подписи Ace и так упорно показывать полное непонимание различных архитектур веб-серверов.
Boris, я в пхп не очень разбираюсь, но вроде бы он не асинхронный? если не асинхронный, то все преимущество nginx банально пожрется выполнением пхп-кода, который будет опять же требовать нитку на себя. или я ошибаюсь?
повторяем в четвертый раз (уже как мантра):
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К комаров....
пожалуйста - MaxClients равно максимальному количеству ниток для всех процессов апача. Соответственно, если поставить MaxClients = 10, то одновременно он сможет обслуживать 10 соединений. Остальные клиенты будут ждать пока эти соединения обслужаться. Ни о какой "туевой хуче" речь не идет.
Кто будет извиняться?
да при том, что nginx легко обходит апач по производительности и по потребляемым ресурсам при отдаче статики на больших нагрузках. а в остальном ни при чем, да.
я шесть лет назад написал хттп-прокси, который держит 8К активных соединений. к сожалению, была выбрана по независящим от меня причинам модель как в апаче. до сих пор имею удовольствие наблюдать сколько времени проц. тратит впустую на переключение контекста.
я с проблемой 10К connections знаком изнутри, а не на уровне "поменяй в конфиге", так что поосторожнее с "мануалами из интернета", ок?
и? вы сами-то читали? или "многа-букаф-не-осилил"/"не читал но осуждаю" ?
цитату вы не привели не из-за величины текста, а потому что приводить нечего.
специально для вас повтор номер 3, цитата из вашей-же ссылки, да простят меня модераторы:
все так же жду цитату про "туеву хучу".
PS: хотел передать привет вашим учителям, да понял что их просто не было, раз уж вы читать не умеете.
очень похожее. только вот непонятно почему в стандартной поставке нет, да и для асинхронной модели только в апреле код закомитили. как результат - если кто это и пользует, так только тот, кто столкнется с проблемой отсылки больших файлов из пхп. вот и пыхтит апач, выполняя бесполезную работу..
Не чистый тест... Похоже у вас отдается not-modified в трех случаях из четырех
Ресурс-то статический? Без обращения к БД ?
Согласен, но пока что, слава богу, это скорее редкость, чем повседневное явление
iopiop добавил 11.10.2011 в 12:51
Умные хацкеры пишут программы ддоса, которые используют глупые киддис :)
Решение простое на самом деле, вводить параметр который жаба-скрипт передает и проверять его на сервере. Ессно, этот параметр периодически менять надо будет
Я выше привел выдержку из документации. Специально для вас переведу
Максимальное количество клиентов которое может быть обслужено одновременно определяется параметром MaxCients.
От вас жду не голословных посылов, а цитату из документации о "туевой хуче"
Как насчет мозг включить? Ресурс нужно отдать в любом случае, что апачем, что nginx. Повторяю, отдать нужно в любом случае. Вопрос заключается в другом, будем ли байтики сначала из кернела гнать в user при чтении файла, а потом из user опять в кернел чтобы в совет передать. Или сразу в кернеле получили, в кернеле же и отдали
Насчет почитать про ФС в линуксе - слив не защитан, хотя бы потому что ФС в линуксе разные бывают
Raistlin добавил 11.10.2011 в 12:15
P.P.S. Вы не знаете что такое mpm-worker? Какой класс школы? Для 5-7 это ещё нормально, а вот для одиннадцатикласника - полное незнание предмета.
И что вы в mpm параметре MaxClient поставите если у вас 8К активных соединений?
Для справки: 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.
А в линуксе как известно нитки и процессы особо по потребляемым ресурсам не отличаются.
Вот и получается что при 8K соединений процессор будет только тем и заниматься что переключать эти нитки, прыгая туда-сюда из kernel space в user space и копируя память туда-сюда почем зря.
Те же яйца, вид сбоку.
Кстати, а апач научился делать zero-copy, когда передача байтиков из файловой системы в сокет происходит без копирования из kernel в user и обратно в kernel? Nginx-то умеет, а вот про апач как-то я не слышал.
iopiop добавил 11.10.2011 в 11:40
Ну поставите вы в параметрах 10 workers, что это значит? Что остальные 490 клиентов будут ждать пока эти 10 workers не освободятся. Память сэкономили, тормозов добавили
Поставить жаба-скрипт на проблемные странички который стучится обратно на сервер и говорит "это легитимный IP, его в белый список"
Боты жаба-скрипт не выполняют