Хостер гонит за высокую нагрузку сайта на DLE? Тогда читайте эту тему :)

Тесты меряют ровно то, что у них написано в заголовке - оверхед на различные методы вызова php-шного кода.

Но интересно, как по вашему влияет использование mod_php или php-fpm на открытие файлов - а интерпретатор и там, и там один и тот же. Если вы предполагаете, что там как-то по разному открываются файлы, или, например, запросы к базе другие строятся, то это ошибка.

Разница между mod_php и php-fpm только в той прослойке, которая начинается принимающим сокетом и заканчивается вызовом функции выполнения php-скрипта. И чем больше php-кода в тесте или операций, типа открытия файла, тем меньше разница в тестах и тем ближе она будет к статистической погрешности. Что закономерно.

Ставим перед Apache nginx в качестве прокса и ситуация выравнивается + получаем полезности Апачи.

Если адекватно настроить Apache то левых форков не будет совсем, только внутри ПХП-шные.

А если учесть что только ленивый так не делает тест получается далеким от реальной ситуации.

Прогнал бенч на ваш сервер:

Failed requests: 31395

м?

Вопрос был — даёт ли php-fpm существенный прирост производительности по сравнению с стандартными решениями. В данном тесте этот вопрос не изучался, изучалось влияние nginx на отдачу - так это и изучать не надо. То есть тест к спору отношения не имеет.

В общем я не понял что с чем сравнивалось. Работал ли апач с nginx как фронтенд. С какой машины делались запросы. Откуда такая куча failed запросов. Откуда столько форков у апача - их должно быть столько же сколько воркеров и не намного больше. Я бы такой тест не принял за обоснование чего бы то ни было — ни за, ни против.

Pilat добавил 25.12.2009 в 04:39

Разница между mod_php и FastCGI в том, что FastCGI грузит один раз код и много раз его использует. CMS из сотен модулей на загрузку файлов тратит кучу времени, именно это даёт прирост в случае fastcgi+perl. php-fpm как-бы fastcgi+php, но не fastcgi на самом деле, как подозревают некоторые, поэтому серьёзного прироста не должно быть.

А теперь самый актуальный вопрос... Внимание (барабанная дробь)...

А где вы видели в наше время хостера, у которого не установлен nginx перед апачем?

nginx перед apache мало что даст, ибо сама суть apache - делать отдельный процесс на каждый вызов и php-fpm - обрабатывать все вызовы статичными процессами в памяти.

Нагрузку и тормоза дают именно форки апача, если же туда поставить apache как worker, то тормозов будет значительно меньше, особенно если процессы worker сделать по числу камней ;)

Andreyka добавил 25.12.2009 в 08:45

Кстати, как на счет теста Битрикс - два апача, один в prefork mod_php, другой worker php-fpm?

Хотел бы дополнить что апач впринципе монстр, и воркер тоже жрет не по потребностям :)

До этого уровня я еще не дошел... Пока я наблюдал только снижение нагрузки на сервер за счет раздачи статики nginx'ом. На скорость повлияло только там, где ресурсов сервера не хватало. Там где было достаточно, снизилась средняя нагрузка, улучшилась живучесть на стресс-тесте.

Если вопрос ко мне - я готов попробовать на своем реальном проекте, но трафика на нем нем, придется эмулировать. Интересно будет сравнить Ваше решение с VMBitrix.

Ок, только mysql на отдельном, чтоб не влиял на тесты

Нет, это неверно. Грузить один раз код - в смысле, executably binary file, это разница между FastCGI и CGI. Т.е. PHP-CGI каждый раз грузит интерпретатор PHP, а у PHP-FastCGI интерпретатор загружается один раз. Но сами php-файлы загружаются и интерпретируются одинаково и в PHP-CGI, и в PHP-FastCGI, и в mod_php. Кэширование загрузки файлов входит в задачу акселераторов типа eaccelerator и zend optimizer, только кэшируются не сами файлы, а уже компилированный опкод.

Работу перловых скриптов в fastcgi не нужно смешивать с PHP, там совершенно разного уровня подход. Когда разрабочик пишет перловый скрипт для fastcgi, он может сделать и прелоад нужных файлов, и инициализацию различных тяжелых структур данных и прочее, что можно вынести из цикла обработки каждого запроса. В случае с PHP, разработчику безразлично, будет ли его исполнять php-fastcgi или mod_php, так как выполнение php-скрипта будет идти одинаково в обоих случаях. Разница только в той самой прослойке между приемом HTTP-запроса и стартом скрипта, про которую я писал раньше.

cvss добавил 25.12.2009 в 12:28

Это не так. В prefork один процесс может обработать последовательно сколько угодно вызовов к php-скриптам (число выполненных запросов можно ограничить в конфиге). Он не будет делать отдельный процесс (fork) на каждый вызов. PHP-FPM в этом аспекте работает точно также - каждый воркер может последовательно обработать сколько угодно вызовов.

Более того, у PHP-FPM в разработке и планах на релиз находится реализация prefork модели apache, для динамического регулирования числа рабочих процессов в зависимости от нагрузки, так как статическое число воркеров - это недостаток.

Ну и, на самом деле nginx перед apache дает все :) Как любой другой HTTP-акселератор. Даже без кэширования, а только снятием на себя передачи данных клиентам.

Ну вот мы и добрались до сути непонимания Вами что именно надо тестировать. Апач не делает форки на каждый запрос, если его не принуждать к этому специально. Занавес...

Pilat добавил 25.12.2009 в 15:12

У Андрейки, вестимо.

Pilat добавил 25.12.2009 в 15:17

Выделенные пункты - это те самые загрузки файлов, либо со скриптами, либо с опкодом. Акселератор ускоряет компиляцию, но не ускоряет загрузку этих файлов. Вот как раз фаза загрузки файлов и оказывает существенное влияние на производительность, по сравнению с "прослойке между приемом HTTP-запроса и стартом скрипта" это влияние практически полностью должно нивелировать преимущества от php-fpm прослойки, и чем более навороченная система, тем сильнее это должно быть заметно.