Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Пока хостер не выключил сервер — можете его подрюкать.
Сам москит тут: 213.239.211.15/ — можете его через ab, или написать там пару комментов.
Статистика мунина тут — 213.239.211.15/munin/localdomain/localhost.localdomain.html
Сам москит тут: 213.239.211.15/ — можете его через ab, или написать там пару комментов.
Статистика мунина тут — 213.239.211.15/munin/localdomain/localhost.localdomain.html
Респект за топик, хоршее доказательство. Но nginx может еще больший прирост давать.
С апачем сравнивать нгинкс — это как жопу с пальцем…
С апачем сравнивать нгинкс — это как жопу с пальцем…
Многие этого незнают
Все-таки да, здесь php получился почти не при чем, так как основное влияние на результаты теста оказывает nginx vs apache, а не mod_php vs php-fpm. И если поставить между клиентом и сервером еще и медленный канал, апач проиграет с разгромным счетом из-за кучи долго отдающихся данных.
Если я правильно понимаю, возникшее там непонимание :) касалось выигрыша, который дает nginx + php-fpm по сравнению с nginx + apache/mod_php. Он и правда должен быть не такой большой.
Если я правильно понимаю, возникшее там непонимание :) касалось выигрыша, который дает nginx + php-fpm по сравнению с nginx + apache/mod_php. Он и правда должен быть не такой большой.
>Если я правильно понимаю, возникшее там непонимание :) касалось
>выигрыша, который дает nginx + php-fpm по сравнению с nginx +
>apache/mod_php. Он и правда должен быть не такой большой.
Мне тоже казалось, что это именно так — как ТС пришло в голову что вопрос в apach vs nginx — загадка.
>выигрыша, который дает nginx + php-fpm по сравнению с nginx +
>apache/mod_php. Он и правда должен быть не такой большой.
Мне тоже казалось, что это именно так — как ТС пришло в голову что вопрос в apach vs nginx — загадка.
php-fpm более производительный, чем mod_php в prefork. Ибо тред менее жруч чем форк.
А откуда треды взялись в php-fpm?
Это и так понятно, что тред менее жруч, чем процесс. Так зачем было сравнивать штуку, которая делает процессы, со штукой, которая делает треды? Если я правильно понял, что такое php-fmp (дела не имел с ним), то его стоит сравнивать с mpm_worker, а вовсе не с mpm_prefork.
2 разных sapi php, 2 разных метода обработки соединений веб-серверами, я бы на apache2 worker + zts php посмотрел
Да тут у Андрея вообще странные условия теста… Выигрыш будет скорее всего в пределах погрешности всяких там колебаний.
Желательно еще обращатся к пхп через сокет, мне кажется это будет немного быстрее.
Требую теста Apache prefork (по 1-2 процесса на кол-во физических ядер)+mod_php+nginx в режиме прокси. :-)
Т.е. на этом сервере prefork должен создавать 4 процесса максимум.
Именно такой конфиг я использую у себя.
Именно такой конфиг я использую у себя.
Они создаст 4 процесса, просто когда их backlog будет забит — напишет что надо повышать MaxClients ;)
Это просто информация, работать будет все отлично, запросы будут собираться в nginx, а обрабатываться в apache по-очереди.
Ну данная связка уже 100 раз обсуждалась, последний Дмитрий Котеров большой коммент поданному поводу давал.
Численная разница будет максимум в некотором количестве памяти в пользу версии без апача (причины понятны), и то ее можно свести к минимуму убрав лишние модули.
Остальное — удобство конфигурирования, тут каждому свое.
Сам часто использую оба варианта, с апачем в середине обычно применяю когда есть правила mod_rewrite и их хочет менять разработчик.
Численная разница будет максимум в некотором количестве памяти в пользу версии без апача (причины понятны), и то ее можно свести к минимуму убрав лишние модули.
Остальное — удобство конфигурирования, тут каждому свое.
Сам часто использую оба варианта, с апачем в середине обычно применяю когда есть правила mod_rewrite и их хочет менять разработчик.
Т.е. производительность Apache2+nginx не особо отличается от просто nginx?
А можно ссылки на обсуждения?
А можно ссылки на обсуждения?
Все лишние модули были убраны с apache, иначе бы он не весил так мало.
Я лично не совсем понял почему «используете вариант с апачем, когда есть правила mod_rewrite». Что вам мешает эти правила прописать для Nginx, а не использовать ради них Апач?
Было бы интересно посмотреть независимое сравнение их с YAWS.
А прогнать тот же тест на Apache+php-fpm не собираетесь для чистоты эксперимента, чтобы ясно увидеть (или не увидеть :) ), что именно nginx быстрее/надежнее Apache, а не php-fpm быстрее/надежнее mod_php?
Вопрос был — даёт ли php-fpm существенный прирост производительности по сравнению с стандартными решениями. В данном тесте этот вопрос не изучался, изучалось влияние nginx на отдачу. То есть тест к спору отношения не имеет.
Теперь про сам тест. В общем я не понял что с чем сравнивалось. Работал ли апач с nginx как фронтенд. С какой машины делались запросы. Откуда такая куча failed запросов. Я бы такой тест не принял за обоснование чего бы то ни было — ни за, ни против.
Теперь про сам тест. В общем я не понял что с чем сравнивалось. Работал ли апач с nginx как фронтенд. С какой машины делались запросы. Откуда такая куча failed запросов. Я бы такой тест не принял за обоснование чего бы то ни было — ни за, ни против.
Хм… Если я правильно понимаю, основное преимущество nginx в том, что он не ест много памяти и процессора на каждый запрос. И его, в большинстве случаев, используют для раздачи статики — картинок, статичных хтмл, стилей, JS и т.д. «Тяжелые» же запросы (обработка php+mysql) отдают апачу.
Т.е. главная цель использования nginx+apache в том, чтобы сервер мог обслуживать большее количество запросов при тех же ресурсах. Ускорение обработки запросов является приятным побочным эффектом.
Т.е. главная цель использования nginx+apache в том, чтобы сервер мог обслуживать большее количество запросов при тех же ресурсах. Ускорение обработки запросов является приятным побочным эффектом.
Мы, к примеру, отдаем и большие файлики nginx'ом, через X-Accel-Redirect (который выдает php скрипт на апаче, проверяющий доступы и т.п. и выдающий на nginx реальное физическое место файла на стораджах)
P.S> в Opera 10.10 каменты перестали писаться
P.S> в Opera 10.10 каменты перестали писаться
Вы это делаете, чтобы апач быстро отдал данные nginx и не висел без дела в памяти пока клиент получает данные по медленному каналу?
В общем да, только немного хитрее (в отличие от «стандартного» метода проксирующе-кеширующего nginx)
Пользователь просит файл вида somehost.com/store/username/filename.ext
Nginx спрашивает у скрипта на апаче этот файлик.
Апач данные не отдает, являясь бекендом для nginx, выдает хидеры:
X-Accel-Redirect с реальным именем файла на дисковой полке (а там система путей-подпапок с разбивкой по символам id файла), откуда файл отдаст сам nginx как статику.
Либо если файл данному пользователю не доступен — скрипт на апаче выдаст нужный отбив 400-404-503, на который nginx ответит уже сам через перехват ошибок.
В итоге апач со скриптом отвечает только хидерами достаточно быстро.
Пользователь просит файл вида somehost.com/store/username/filename.ext
Nginx спрашивает у скрипта на апаче этот файлик.
Апач данные не отдает, являясь бекендом для nginx, выдает хидеры:
X-Accel-Redirect с реальным именем файла на дисковой полке (а там система путей-подпапок с разбивкой по символам id файла), откуда файл отдаст сам nginx как статику.
Либо если файл данному пользователю не доступен — скрипт на апаче выдаст нужный отбив 400-404-503, на который nginx ответит уже сам через перехват ошибок.
В итоге апач со скриптом отвечает только хидерами достаточно быстро.
Т.е. файловая операция запись + файловая операция чтение быстрее передачи через tcp на одной машине? Хотя важно, чтобы только запись была быстрее этой передачи… Это так? Апач пишет на диск быстрее передачи через tcp на локалхост?
В нашем случае никуда ничего не пишется.
Файлы лежат на дисковой полке, которая доступна машине с nginx (для nginx это локальные файлы)
Для пользователя удобные ссылки на файлы, конечно же не совпадающие с физическим путем к файлам.
У nginx просят файл, nginx лезет на апач бекенд по tcp на другую машину и спрашивает у его скрипта что-то типа: пользоватеь такой-то просит файл такой-то. Скрипт проверяет доступ пользователя к файлу (его устанавливает владелец файлика, права хранятся в базе), вычисляет физический путь к файлу в ФС полки. И отдает эту информацию на nginx. А уже тот отдает файл с себя, что он умеет делать быстро и не напряжно по ресурсам. Если бы отдавали апачем — на каждую отдачу висело бы по апачу с mod_php и тонной обвеса долго и печально.
Файлы лежат на дисковой полке, которая доступна машине с nginx (для nginx это локальные файлы)
Для пользователя удобные ссылки на файлы, конечно же не совпадающие с физическим путем к файлам.
У nginx просят файл, nginx лезет на апач бекенд по tcp на другую машину и спрашивает у его скрипта что-то типа: пользоватеь такой-то просит файл такой-то. Скрипт проверяет доступ пользователя к файлу (его устанавливает владелец файлика, права хранятся в базе), вычисляет физический путь к файлу в ФС полки. И отдает эту информацию на nginx. А уже тот отдает файл с себя, что он умеет делать быстро и не напряжно по ресурсам. Если бы отдавали апачем — на каждую отдачу висело бы по апачу с mod_php и тонной обвеса долго и печально.
Теперь понятно. Действительно, нестандартная и интересная схема. Обычно редиректы используют для таких случаев — проще, но плюс один запрос к nginx.
Она стандартна. Описана в доке касающейся X-Accel-Redirect, ну и по идее это один из немногих способов вынести логику на основной бекенд с Apache+mod_php с готовым «движком» не написав эту логику отдельно под тот же PHP-FPM.
Ничего нестандартного, такая же возможность есть в Apache (mod_sendfile) и в Лайти.
Основное приемущество что сайт обрабатывают 4 процесса php + nginx. А вот Apache начинает форкать на каждый запрос по процессу и иногда не успевает отфоркать достаточно процессов. Отсюда и ошибки.
Я с большими нагрузками дела не имел… Действительно бывают ситуации, когда апач не успевает создавать процессы и сервер гибнет, даже имея достаточные ресурсы для их обработки именно из-за слишком большого времени создания процесса? Я до сих пор считал, что основная проблема в этом случае — проблема с памятью, которую апач всю занимает своими процессами… (БД и медленные каналы не рассматриваем сейчас).
он начинает форкать на запрос по процессу, т.к. настроен неправильно, вот и все
This Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3.
Так что он будет полюбому форкать на запрос если кончились процессы и беклоги забиты.
Так что он будет полюбому форкать на запрос если кончились процессы и беклоги забиты.
Объясните, пожалуйста, одну вещь. Есть у нас тут 2 алгоритма обработки запросов — «на каждый запрос создаем процесс» и «на каждый запрос создаем тред». И в apache, и в ngnix можно оба реализовать, используя разные модули и настройки.
Почему Вы тогда на ngnix настроили работу по одному алгоритму, на apache — по другому, потом измеряете скорость и делаете вывод, что ngnix быстрее, чем апач? Это же ненаучное исследование, оно ничего не показывает, и, более того, отдаляет людей от понимания сути.
Можно точно так же было настроить ngnix, чтоб он плодил новый процесс на запрос, и апач, чтоб он создавал тред, были бы обратные результаты.
Почему Вы тогда на ngnix настроили работу по одному алгоритму, на apache — по другому, потом измеряете скорость и делаете вывод, что ngnix быстрее, чем апач? Это же ненаучное исследование, оно ничего не показывает, и, более того, отдаляет людей от понимания сути.
Можно точно так же было настроить ngnix, чтоб он плодил новый процесс на запрос, и апач, чтоб он создавал тред, были бы обратные результаты.
Ну пипец.
2) Очень умное решение — поставить 10 тыш клиентов. Естественно апачь при таком раскладе наплодит 700 процессов, которые естественно сожрут всю память, система естественно войдет в глубокую жопу-своп, и естественно не сможет нормально работать. Это не тест, какой сервер быстрее, это тест «Как завалить апачь».
Apache1) Зачем отключен Keepalive?
Отключен Keepalive, а MaxClients и ServerLimit установлены в 10240
2) Очень умное решение — поставить 10 тыш клиентов. Естественно апачь при таком раскладе наплодит 700 процессов, которые естественно сожрут всю память, система естественно войдет в глубокую жопу-своп, и естественно не сможет нормально работать. Это не тест, какой сервер быстрее, это тест «Как завалить апачь».
The MaxClients directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced.
Раскладка по утилизации CPU тоже явно не в пользу Apache.
А разве не наоборот? idle на правом участке больше
Считаю данный тест бессмысленным. Если хотели сделать интригу, то надо было сравнивать Nginx vs Apache MPM worker хотя бы.
Когда там будет стабильно работать mod_php, тогда и проверим.
А mod_php не стабильно работает с worker'ом? Предрассудки, или просто не так готовите.
Нестабильно с mod_php mpm worker может работать (работал) из-за ошибок в mod_php, библиотеках и интерпретаторе php, которые делают код не thread-safe.
Если ошибки есть, то они точно так же будут влиять на любую другую конфигурацию, в которой php будет запускаться через треды, в.т.ч. на ту, что в статье. MPM worker стабилен ровно настолько же, насколько стабилен любой другой способ запуска php через треды.
Если ошибки есть, то они точно так же будут влиять на любую другую конфигурацию, в которой php будет запускаться через треды, в.т.ч. на ту, что в статье. MPM worker стабилен ровно настолько же, насколько стабилен любой другой способ запуска php через треды.
А что мешало запустить PHP через FastCGI?
Спасибо, за ваш труд, пишите еще, у вас хорошо получается ;)
ИМХО, сравнение было бы гораздо интереснее, если бы в бенчмарке апача перед ним стоял NGINX как реверс-прокси. А так результаты вполне предсказуемы, конечно :D
Если гонять тест на производительность, то nginx с php-fpm следует равнять с Apache2 mpm-worker, например.
BTW на графике cpu кто-кого обогнал?
BTW на графике cpu кто-кого обогнал?
еще написали как правильно кэширование в nginx настроить. а то у меня получилось, что сайт тупо весь закешировался, проц в IDLE на 99%, а залогиниться не могу. приэтом контент таки обновляется.
Апач, поставленный через app-get неработоспособен вообще. На динамических сайтах апачега с пхп нужно собирать статичным бинарником и затачивать под каждый конкретный проект.
почему неработоспособен?
Ну хотя бы потому, что динамическое подсасывание модулей очень сильно его тормозит. А дефолтно он именно так и устанавливается. Апачег нужно тюнить и тюнить вдумчиво под конкретный проект, тогда он уделывает и нжинкса и лайтхттпд с боооольшим отрывом. Это опыт поддержки проектов с миллионами хостов в сутки.
апач в принципе при отдаче не может уделать nginx. Никак и ни при каких настройках. Разве что сравнивать nginx как запускатель скриптов и апач как запускатель скриптов, без учёта медленных клиентов.
Вы просто не видели, какие результаты дает apache+php=single-binary.
да хоть убейтесь — клиент, читающий ответ Вашего скрипта в течении минуты, всю эту минуту будет отжирать кучу памяти по сравнению с nginx, и в результате тормозить систему, которая имет хорошие шансы залезть в своп. Может быть, один запрос и быстрее отдаст апач без nginx, но это нереальный случай, реальный — много параллельных запросов.
какие именно проекты? ссылки и описание архитектуры?
А почему php цепляется через TCP, а не по файловому сокету?
Бенчмарками не покормите?
С налёту нашел тока про рельсы: macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-load-balancer-tonight/
С налёту нашел тока про рельсы: macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-load-balancer-tonight/
Как показывают опыты на Celeron 500, Nginx совсем не быстрее Jetty (без шуток).
требую теста apache-worker! )
Чтобы он слил? Вот здесь отлично документированный тест www.pentarh.com/wp/2008/07/11/test-results-apache-vs-php-fcgi/
Правда там отдельно подбирали оптимальное число процессов для каждой схемы.
Вкратце: все варианты практически не отличаются, но немного вырывается вперед apache1+mod_php.
Правда там отдельно подбирали оптимальное число процессов для каждой схемы.
Вкратце: все варианты практически не отличаются, но немного вырывается вперед apache1+mod_php.
Андрей, а ты здесь что с чем тестировал и какова цель эксперимента? Я пока что не вижу ничего кроме сравнения поведения газеты в дистиллированной воде и соляной кислоте. После озвучивания цели, очень хотелось бы узнать о методике выбора параметров тестируемых компонентов. Вот прямо картинкой и кружочком те места которые нас интересуют.
Появилась необходимость поработать над проектом в связке «Nginx + Php-fpm», но до сих пор была установлена связка «Nginx + Apache».
Вопрос: могут ли сосуществовать и та и другая связка вместе?
Например какие-то server прокидывают на Апач, а какие-то на Php-fpm?
Мне интуитивно кажется что такое возможно. Но, так и не смог сейчас толком этого добиться.
Почему-то всё равно схватывает и бросает на Апач, при том что fastcgi_pass php5-fpm-sock;
Где php5-fpm-sock — это upstream на сокет. (https://coderwall.com/p/hmsr5a)
Также использовал вот это (http://help.ubuntu.ru/wiki/nginx-phpfpm) для настроек.
Вопрос: могут ли сосуществовать и та и другая связка вместе?
Например какие-то server прокидывают на Апач, а какие-то на Php-fpm?
Мне интуитивно кажется что такое возможно. Но, так и не смог сейчас толком этого добиться.
Почему-то всё равно схватывает и бросает на Апач, при том что fastcgi_pass php5-fpm-sock;
Где php5-fpm-sock — это upstream на сокет. (https://coderwall.com/p/hmsr5a)
Также использовал вот это (http://help.ubuntu.ru/wiki/nginx-phpfpm) для настроек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Nginx + PHP-FPM против Apache2 Prefork + mod_php