Pull to refresh

Comments 35

PHP встроен в mod_php Apache, что должно ускорять его.

Откуда такие выводы?
Хорошо, а как тогда можно сформулировать?
Apache+mod_php ускоряется относительно Apache + PHP-CLI over CGI, конечно же.
С mod_php не поднимается каждый раз конфигурация и окружение php на каждом запросе. Только в момент запуска Apache. Так же все включенные в конфигурации расширения так же не подгружаются на каждый запрос (ну за исключением dl('extenstion') ).
По поводу .htaccess и AllowOverride было написано еще в древней книжке o'reilly «Тюнинг Веб-сервера». Все что нужно в .htaccess лучше перетащить в конфиг и включать AllowOverride только там, где это необходимо через конфиг. Ибо разрешение его с DocumentRoot будет вести к полному перечитыванию ВСЕХ вложенных папок (удовлетворяющих запросу) по пути для поиска .htaccess.
Особенно это будет адово тормозить, если в папке с AllowOverride All (и .htaccess соответственно) лежит пара тысяч файлов на одном уровне.
тут, кроме htaccess естьеще многоопределяющих факторов… например — дефолтные конфиги, сколько было запущено вокеров у апача и фпм-а? Как была настроена связь nginx-php (к бабке не ходи, а через unix сокет — будет быстрее)?
Через unix сокет будет скорее всего чуть быстрее, чем через реальный ip подвешенный на физический ethX. Это понятно.
Но не факт что сильно быстрее, чем через loopback interface. Помнится была тема (не знаю насколько реализована), что в Linux можно пакеты идущие через lo пулить мимо роутинга и netfilter
Только вот Apache вроде не умеет на сокете работать (если цеплять его backend'ом к nginx), так что для одинаковых условий в любом случае надо оба тестить на loopback или реальной сети
Очень было бы интересно узнать как это сделать «пакеты идущие через lo пулить мимо роутинга и netfilter». Я только нашёл как убрать NOTRACK
… а теперь запускаем все запросы не подряд, а одновременно, и...
Nginx всегда славился количеством соединений, которые он может одновременно удерживать, в том числе медленных, скоростью отдачи статики, и объемом потребляемых при всем этом ресурсов. Но для меня всегда было очевидно, что php будет работать примерно с одинаковой скоростью независимо от того, на каком сервере он запущен.
Я же явно сказал, что PHP не ускорится, зато при смешении языков разница в производительности появится.
Да, вы сказали об этом явно. Но в целом статья, не смотря на попытку маскировки под исследование, оказалась капитанской. Доказываемые в ней утверждения, я считаю, не требуют доказательств.
Причем тут «смешении языков»? Попробуйте повторить тест на 1000 медленных соединений. =)
И да, бенчмарк без единого конфига и описания методики — это убедительно.
Про бенчмарк спасибо. Виноват, исправлюсь :)
UFO landed and left these words here
В том числе, собственно почему нет?
Вообще почти любой ЯП через cgi и в путь!
В этом случае будет сравнение
Nginx + PHP-FPM vs Nginx + (Apache+mod_php).
В итоге «медленные» запросы будут так и так рулиться nginx'ом. А mod_php и php-fpm сравнимы по скорости (все равно «под капотом» одно и тоже)
В первую очередь в сравнение apache и nginx нужно сравнивать модель обработки запросов. А между apache mpm_prefork (именно он используется при mod_php) и nginx разница огромна уже в самой идеи.
Поэтому чаще всего и используют апач для скриптов и nginx для статики
Методика тестирования никуда не годится. Конфигурации железа нету. Ниочем.
разница будет весьма и весьма небольшая. потому что сравниваются по факту два prefork-сервера.
Это вы на какой комментарий ответили? И откуда взялся второй prefork-сервер?..
это я комментарий к статье оставил :)

php-fpm — это вполне себе prefork-сервер: по процессу на запрос. кроме того, умеет спавнить воркеров on demand.
сравнение из разряда «кто сильней — слон или кит». и, как тут уже написали, не представлен третий вариант: nginx в качестве frontend с apache+mod_php в качестве backend.
По мне статья не полная, если в ней не указан hhvm. На сколько вырастет производительность если использовать Apache + hhvm и для статики Nginx?
Какое-то сравнение серверов в вакууме. Ни тебе потребления ресурсов, ни конфига железа…
А не достаточно того что оба теста проводились на одном и том же сервере? Конфигурация железа будет играть большую роль?! Если вы возьмете топовый 4-х процессорный сервер, с тонной оперативки или возьмете E3-13XX с 8-16гб на борту разница по запросам все равно составит ~5%

ЗЫ Если не прав, поправьте.
Ну, к примеру, результаты теста сильно зависят от соотношения сетевых задержек при обмене данными между клиентом и nginx — и между nginx и php-fpm. Если nginx и php-fpm запущены на одном сервере, то важно, тестовый клиент находится на том же сервере — или все-таки между ними есть какое-то расстояние.
Даже если между сервером на nginx и клиентом есть расстояние, то между апачем и клиентом точно такое же расстояние, этого требуют условия тестирования, иначе глупо сравнивать два сервера с разными клиентами, результат будет искажен. По поводу задержек между нгинХ и пхп-фпм, думаю что схема построена через сокет, тк иначе тест с апачем так же будет не корректен. Можно еще конечно целое облако пхп-фпм'ов нагородить и сравнить с одинм сервером апача, или облако апачей, а первый как проксирующий апач, но это уже фарс, думаю что все это понимают.

Так что я, читая статью, представлял себе, что конфиг сервера с апачем равен конфигу сервера с нгинХ+пхп-фпм, расстояние до клиента — одинаково, и все компоненты обоих софтверных серверов располагаются на одном физическом сервере, под одной и той же операционной системой, на которую поставлены из нулевого состояния. (на чистую систему)
Дело не в том, одинакого расстояние до клиента — или нет. А в том, есть ли оно вообще. Сейчас nginx вроде как проигрывает апачу 15%. Но если брать реальную ситуацию (клиент находится далеко), эта цифра должна уменьшиться.
Я сам приверженец связки NginX + php-fpm, она мне как-то больше нравится, да и облако их пхп-фпм'ов легко наращивать, я согласен с вами что при реальном использовании разница может сократиться в разы, но как мы все понимаем это зависит от клиентов и их каналов до нашего сервера. NginX считается более легковесным при отдаче статики, а пхп обрабатывается php-fpm, как правильно заметили выше, скорость пхп не меняется в зависимости от обвязки, а накладными расходами можно пренебречь, тк они что там, что там будут примерно одинаковы, а если учесть что фпм и нгинХ в большинстве случаев разносятся по разным серверам и облако фпм-ов можно наращивать, то на мой взгляд запариваться из-за лишних 5% производительности, в сравнении с удобством масштабирования — может кому — то хочется, но не мне.
Ключевой момент тут ещё в том, а как общался nginx с php-fpm.

Apache с php общался напрямую в памяти. Если при этом nginx был настроен слать в php всё по tcp, да ещё и без keepalive, то уже неравные условия. Плюс имеют значение настройки размеров буферов для приема ответа, количество рабочих процессов с php, если у apache было 100 рабочих процессов, а у php-fpm было 10, то опять условия неравные. И как эти процессы запускались, заранее или ondemand.

Потом настройки логгирования, а они были одинаковы? Когда тест состоит из выдачи «Hello world», то write() одной строчки в файл уже вносит заметную задержку.

Ну и вообще любые цифры без указания погрешности — это ложь. Любые результаты и выводы, без исследования первопричины — бесполезны, поскольку ни чем не подкреплены, кроме субъективного впечатления автора от своих тестов, на конкретно своей системе, в своей конфигурации, которую он к тому же не приводит. Всё это не воспроизводится. Вот человек тоже провел тесты и намерял наоборот, nginx+php-fpm чуть быстрее: systemsarchitect.net/apache2-vs-nginx-for-php-application/
Про процесс тестирования писал выше, при прочтении статьи рассчитывал что кол-во воркеров, как и коннект были идентичны, логи отключены, либо пишут одинаковую инфу, воркеры запущены заранее и там и там. Но это мои догадки, основанные на дефолном конфиге Nginx+php-fpm. Можно перейти к детальному анализу не только конфигов фпм-а но и php.ini, я считаю что все конфиги были стоковыми или подогнаны под конкретную задачу, в следствии чего были идентичными, а считаю так, потому, что нет обратной информации.

ЗЫ не претендую на истину, все выше изложенное есть мое мнение и не более.
ЗЗЫ Можно долго гадать что там было и как тестировалось, давайте исходить из того, что все конфиги были по большей части дефолтными, немного подогнанными друг к другу для чистоты тестов.
Если конфиги были стоковыми, то, как минимум, количество рабочих процессов fpm и апача различалось в разы. Ну и если под стоковым nginx+php-fpm конфигом понимать закомментированные строчки из nginx.conf по умолчанию, то да, там tcp:

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}


Можно перейти к детальному анализу не только конфигов фпм-а но и php.ini, я считаю что все конфиги были стоковыми или подогнаны под конкретную задачу, в следствии чего были идентичными, а считаю так, потому, что нет обратной информации
Мой опыт общения с подобными «исследователями» и «исследованиями» подсказывает, что скорее всего ровно наоборот — буквально всё было сделано неправильно.
Я скорее про конфиг Фпм-а говорил, который по умолчанию работает на сокете, в nginx-е его надо менять… Я писал что конфиги немного подгоняются друг под друга, но видимо этот момент проигнорирован. Дальнейшую дискуссию предлагаю закончить, тк можно привести кучу доводов за и кучу против, все равно каждый останется при своем мнении.)

Мой опыт общения с подобными «исследователями» и «исследованиями» подсказывает, что скорее всего ровно наоборот — буквально всё было сделано неправильно.

Не исключено.
Only those users with full accounts are able to leave comments. Log in, please.