Запускаем php 8 с jit в docker за 5 минут

[razielvamp]

Вопрос не совсем по теме. Но видел реализацию, когда в проде так же запускали пхп в докере в built-in сервере, и сверху докер с проксирующим nginx. Типо один сервис — один контейнер.
Из-за этого не страдает эффективность и скорость ответа (ощутимо) в отличии от метода, когда все обрабатывает nginx (или apache) через соответствующие библиотеки внутри себя?

[avengerweb]

nginx не имеет в себе встроенных модулей php. Для nginx используется обычно php-fpm. Конечно, если вы работаете через TCP сокеты оверхед будет (заметите вы его или нет, вопрос другой), если очень хочется никто вам не запрещает прокинуть unix-сокет, работать будет быстрее особенное если у вас HA, с другой стороны если у вас HA, и контейнеры, то скорее всего вы планируете горизонтально скалироваться, а тут кроме tcp вам пойти некуда, а все проблемы оверхеда решать еще одним сервером, куда проще чем заморачиватся с тонкой настройкой стека. (не зря же владелец амазона так быстро стремится к своему триллиону)

[TPbIHTPABA]

Немного оффтоп но все же nginx имеет модули для php и части популярных языков
unit.nginx.org.
Но сути это не меняет, большинство действительно используют связку nginx + fpm. Что больше подходит для docker-like подхода «один контейнер — один процесс».

[xtrime]

Плохая идея использовать в продакшене php -S, так как он однопоточный, то есть обрабатывает только один запрос одновременно.

Допустим мы вызываем какую нибудь долгую операцию, типа такой:

<?php

sleep(100);
echo 'test' . PHP_EOL;

В следующие 100 секунд наш контейнер не будет обрабатывать другие запросы, даже если они моментальные.

Nginx и apache решают эту проблему с помощью воркеров. Даже если один воркер блокируется, то остальные продолжат отвечать на запросы.

[FlamyXD]

По моему opcache.enable_cli=0 стоит по умолчанию не просто так

[xtrime]

Я читал на SO этот ответ. Но эту формулировку, видимо, удалили c php.net. Значит эта инфа более не актуальна. www.php.net/manual/ru/opcache.configuration.php#ini.opcache.enable-cli — тут ничего не написано про отладку.

Зато в документации по opcache.enable написано: «Если запрещено, код не будет оптимизироваться и кешироваться.»

[ainu]

Провёл несколько тестов для проверки php cli opcache. Если в процесс измерения времени входит собственно загрузка, то разница есть (при включенном кеше само собой).
Но если код уже запущен (например в цикле сокет слушает, как это используется в php-cli например) то разницы нет. Т.е. вся выгода при всякого рода запуске множества тестов, а для продакшна приложений на всякого рода roadrunner разницы толком нет.

[xtrime]

У вас opcache.enable_cli включен? При работе bench.php есть прибавка в скорости?

В реальных приложениях все обычно в IO упирается. Но в одном проекте есть парочка «толстых» скриптов, попробую потестить сколько enable_cli дает прибавки в скорости там.

[ainu]

Включал и выключал. Разницу не вижу. У меня пока на тестах упор в IO и (как ни парадоксально) в https шифрование.

enable_cli будет работать, если скрипт выполняется регулярно. В случае, если один раз запустили, и неделями работает, никакой пресловутой «оптимизации» не видно, как не выжимай. В документации тоже обнаружил момент с отмутсвием толкового описания оптимизации, но львиная доля опкеша работать не должна в таком режиме.

bench.php не запускал. При нескольких запусках прибавка само собой должна быть (кешируется же скомпилированный байткод).

[xtrime]

В том то и дело, что я даже чистый контейнер поднимал и opcache_reset(); делал. И всегда даже первый запуск работает в 2 раза быстрее с enable_cli=1.

Сейчас тестирую реальные приложения. Результаты получаются разные.

Команда из проекта на работе (время работы самого скрипта, время запуска не учитывается):

#Прогоны со стандартным конфигом: 
4.059s,4.113s, 4.166s, 4.022s, 4.021s 

#Прогоны с opcache.enable_cli=1:
4.089s, 3.978s, 3.947s, 3.86s, 3.838s, 3.736s

opensource проект, парсинг dom дерева (без учета получения данных по сети): github.com/xtrime-ru/ICA/blob/master/app/Parsers/HtmlParser.php#L19

#Прогоны со стандартным конфигом: 
0.038s, 0.04s, 

#Прогоны с opcache.enable_cli=1:
0.058s, 0.057s

То есть в одном проекте получили ускорение на 200 мс., а во втором случае замедление на эти же 200 мс…

В итоге, как и пишут в умных книжках, надо всегда тестить для конкретных приложений.