PHP код обрабатывается одинаковое время, какой бы веб-сервер вы бы не использовали или нет?

А где про это? Вы не поняли суть. Про апач только это

$ apachectl -V | grep -i mpm
Server MPM:     prefork

Иными словами, если апач prefork, картинка в top будет похожая,

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                    
  54020 www       20   0  684828  36104  23936 R  26,2   0,2   0:30.67 php-fpm                                                                    
  54259 www       20   0  684828  37000  25152 S  25,8   0,2   0:23.47 php-fpm                                                                    
  54019 www       20   0  684828  36104  23936 R  24,5   0,2   0:28.80 php-fpm 

только вместо зрз-азь будут процессы апача.

Еще раз суть эксперимента.

Запустили зрз скрипт из консоли. Код в цитируемом сообщении есть. Прочитать 56мб джисон (46943 шин) и декодировать.

$ php -f /home/www_data/pyh.php #при "все спокойно"
phpversion: 8.0.1
Time: 221.245ms; Mem: 168391056; PeakMem: 168391408; StrLen:56570903; Count: 46943 
Time: 198.521ms; Mem: 168391056; PeakMem: 168391416; StrLen:56570903; Count: 46943 

~ 200 мс

запустили ab -n 15000 -c 100 -H "User-Agent:Mozilla"   http://p.php/  Имитируем нагрузку.

И пока оно 15000 запросов делает, пускаем тот же скрипт из консоли

#при "нагрузке"
$ php -f /home/www_data/pyh.php
phpversion: 8.0.1
Time: 410.268ms; Mem: 168391056; PeakMem: 168391408; StrLen:56570903; Count: 46943 
Time: 571.403ms; Mem: 168391056; PeakMem: 168391416; StrLen:56570903; Count: 46943 
Time: 533.022ms; Mem: 168391056; PeakMem: 168391416; StrLen:56570903; Count: 46943

Миллисекунд понадобилось более чем в 2 раза.

По моему, весьма наглядно.

Зы: если смущает ,  http://p.php/ то все просто. локальная зона php обрабатывается. httpd на этой машине дизаблед

server {

    server_name    ~^(.*?)\.?(?<d_name>[^\.]+)\.php$;
    set        $sub_name    $1;
    set        $x_root /var/www/php/$d_name/public;
....
    
       fastcgi_pass  unix:/var/run/php-fpm/www.sock;
....

$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Drop-In: /usr/lib/systemd/system/httpd.service.d
   Active: inactive (dead)

Начали за здравие, как говориться... Вы и есть клиент! Вы клиент передаёте данные вебсерверу, он передаёт их PHP,  PHP обрабатывает и отдаёт вебсерверу, а потом возвращает клиенту т.е. вам результат. И тут проблему НЕ в PHP.

Вы тут доказываете, что нагрузка процессора влияет на выполнение PHP?! Серьёзно?

Я думаю лучше это включить архивирование 10 ГБ файла, а потом уже делать проверку PHP из консоле. Так же "интересны" результаты :)

Если отвечать на прямой вопрос про единичный скрипт, выполняющийся 5сек (а не выдумывать условия типа ab -c 300 - долбежка 300 запросами одновременно по этому скрипту), то да почти без разницы будет это nginx или apache.

На скорость выполнения (повторяю, именно в этом случае - один запуск долгого 5-секундного скрипта) гораздо сильней влияет версия php, настройки php.ini (наличие opcache, обработка ошибок, модули подключенные и т.п.), скорость процессора (не мощность, не производительность, а именно single-thread скорость, зависящая от архитектуры/свежести ядер cpu и тактовой частоты), чем микро-разница между apache и nginx.

Также стоит учесть, что тот же apache с php может взаимодействовать ну очень по-разному (mod_php или cgi например). И то, что если выключить в apache поиск и выполнение .htaccess, то он не так уж радикально будет отставать от nginx (ну может кроме занимаемой памяти).

Плюс очень сильное влияние оказывает работа opcache в php. Поэтому без подробного сравнения всех конфигов нельзя ничего однозначно утверждать. Я вот даже когда делал тесты ниже столкнулся с загадкой почему под nginx/php-fpm скрипт выполнялся примерно на 100мс дольше... оказалось скрипт довольно древний и под php7.4 выдавал кучу deprecated сообщений в процессе выполнения. Когда заглушил эти ошибки в php.ini, результат пришел в норму.

Так что нельзя вот так безапеляционно заявлять, что nginx быстрей apache. Очень много нюансов и очень зависит от конкретных задач.

Итак:

Я с ходу не нашел на столько медленного и тяжелого скрипта, взял вот этот:

http://www.php-benchmark-script.com

Запускал у себя на домашнем роутере, а не где-то на сервере в инете, где постоянно бы влияли на результат соседи.

Он в это время совершенно ничего не делал и можно считать замер более-менее точным.

Проц E5-1630v4 с постоянной частотой 3.8-4.0ггц (не в спящем режиме каком-то).

Везде выставил одинаковую версию php 7.4 и одинаковые настройки php.ini и делаю 3 прохода подряд.

1) Запускаю bench.php из коммандной строки, т.е. под php-cli без включенного opcache в php.ini

Итого отправная точка: ~0.585сек рисует результат сам скрипт и около 0.59сек итого рисует нам time

2) Opcache в php-cli - это конечно не тоже самое, когда php запущен все время (php-fpm или mod_php например) и держит в памяти опкоды. Однако даже на время выполнения одного скрипта он может немного повлиять на результат.

Запускаю тоже самое, с opcache.enable_cli=1 в php.ini

Что изменилось: ~0.515сек (0.07сек выигрыш - 13%) и около 0.53сек итого по результату time

Т.е. однозначно, включение opcache даже в cli дает прирост. Какой именно - очень очень сильно зависит от самого скрипта и от их количества.

Естественно под веб-сервером, если php правильно настроен и запущен всегда с выделенным достаточным объемом памяти под opcache, и если скрипт будет не один, а к примеру wordpress с кучей php скриптов - результат вкл/выкл opcache может быть сильно более заметен.

И там еще будет влияние так называемого "холодного старта", т.е. в первый запуск будет чуть медленней, а потом уже чисто из opcache выполняться может заметно шустрей.

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

3) nginx -> apache/mod_php

В итоге видим примерно те же 0.525-0.530сек по результату скачивания скрипта wget'ом с веб-сервера.

+/- в пределах погрешности, хотя и самую кроху шустрей, чем из под cli - ведь opcache тут уже работает полноценно как и должен.

Повторяю, на большем количестве скриптов результат был бы более заметен (не в пользу php-cli).

4) nginx -> php-fpm

Снова как видим все в пределах погрешности измерений ~0.525сек

Так какой правильный вывод? Именно в этом случае разницы не будет - хоть 0.5сек, хоть 5сек скрипт будет выполняться +/- одинаково не только из под apache или nginx, но даже из под php-cli (только если opcache.enable_cli будет выключен, то получится немного заметнее медленней).

Но! Не путаем это с реальными сайтами. В который раз повторюсь, там где не одиночный долгий скрипт, а много-много php файлов - там работа opcache будет куда более заметна. И в зависимости от нагрузки (количество запросов в секунду прилетающих на сайт) уже может вылезти различие между apache и nginx. Но это не касается обычных мелких сайтов, на которых и 1 запроса в секунду не приходит. Для них важней иметь пусть меньшее количество, но более высокочастотных ядер процессора. У сайтов же с большим траффиком все не так, не нужно их приплетать куда не следует. Да, там по итогу меньше нагрузка и больше скорость (суммарная на всех, а не у каждого отдельно взятого запроса) может получиться на 16-ядерном 2ггц процессоре, чем на 4-ядерном 4ггц. И какие-то минимальные (в обычных ситуациях) преимущества nginx могут также всплыть более ярко.

Еще раз - с уверенностью можно сказать, что один 5-секундный скрипт будет выполняться одинаково и под apache и под nginx. При условии конечно же одинаковых настроек php и если под apache совсем уж плохо все не настроено.

Про загрузку проца, вроде ничего не говорил. Посыл больше к этому:

$ sudo cat /proc/loadavg
0.08 0.33 0.50 2/1876 53130  #все спокойно


$ sudo cat /proc/loadavg    #аб тест 15000 запросов на локальный сайт nginx+php-fpm
5.30 1.42 0.78 59/1939 54025 

В 1 случае 2 активных процесса, во втором 59.

$ apachectl -V | grep -i mpm
Server MPM:     prefork

Каждый хтмл, имеет, пусть 30 цсс, джиэс, картинок, шрифтов и т.д. prefork => каждый запрос - процесс. В отличии от нгинкс Пусть 100 одновременных запросов. Спрогнозируйте load average

Сейчас, еще раз пустил. Как то так

Немного времени есть. Еще эксперимент. Та же метода. Грузим, смотрим время исполнения. Только 15000 запросов к сайту python+aiohttp

htop

Совсем немного процессов. 2 сокета + нгинкс воркеры.

Ну да, так и записано.

Результат выполнения консольного пыха

Разница есть, но не в 2 раза, как когда засрал машину php-fpm процессами.

Тут вообще какая-то дикость происходит 😀

Но в "экспериментах", вы просто грузите систему (процессор, диск, память) с одной стороны... и с другой запускаете скрипт, которому не предоставили ресурсы максимально быстро (как если бы это было при минимальной нагрузке). 

Интерпретируются.

В 8 потоков с pbzip2, тогда будет и PHP-скрипт точно уж попадет в очередь 👍 Хотя, хватит даже 4, если 4 физических ядра, а остальное HT.