Точно программист? Есть понятие виртуальной машины. Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора. То есть, чтобы вам писать всегда на одном языке не зависимо от процессора и операционной системы, вам нужна некая прослойка между вашим кодом и собственно процессором, эту роль выполняет виртуальная машина, в том числе это и JVM у Java, CLR у си шарпа и так далее. Вот ваш код транслируется в опкод (байт код для виртуальной машины) и потом уже исполняется на виртуальной машине php. Никуда её устанавливать не надо, она является частью PHP, так сказать Zend Engine.
Вы же понимаете, что ваше мнение ничего не стоит, так как вы никто по сути в мире разработки?
А вам бы начать с азов, чтоб мы друг друга понимали и мне не приходилось писать на несколько страниц объяснений элементарных вещей
Так погодите, чем интерпритатор то не угодил? Даже некоторые процессоры являются интерпритаторами, это просто термин, который обозначает что анализ и выполнение идет во время чтение, а не заранее, если вы уже считали то разницы нет, интерпритатируемый язык хуже компилированного только на этапе старта (прогрева), под капотом там все тоже самое. На каком сервере работает PHP, у хостера что ли на сервере, что за чушь вы несете? Почитайте чуть глубже погрузитесь в инструменты https://habr.com/ru/company/badoo/blog/327068/ узнаете что такое виртуальная машина PHP и как там все под капотом работает.
Именно это и делает эта либа =)) 6 секунд на установку и настройку, выше уже показали
Интерпретатор - это программа в которой заложены механизмы обработки команд какого либо языка программирования.
Компилятор - исходный код языка программирования преобразует в машинный код.
Давайте воспользуемся википедией?
Интерпрета́тор (англ. interpreter ıntə:'prıtə[1], от лат. interpretator - толкователь[2]) — программа (разновидность транслятора), выполняющая интерпретацию[3].
Интерпрета́ция — построчный анализ, обработка и выполнение исходного кода программы или запроса (в отличие от компиляции, где весь текст программы, перед запуском, анализируется и транслируется в машинный или байт-код, без её выполнения)
Любой код переводится в машинный или байт-код для VM, php не исключение. Когда код уже проанализировался (был переведен в байт код), он уже не отличается от скомпилированной программы по сути, по этому разницы как таковой вы не заметите, в нашем рассматриваемом случае, когда вы запускаете/стартуете код php в виде демона, вы его как бы компилируете в байт-код который висит в памяти.
Именно этот недостаток убирают такие библиотеки
Еще раз объясняю, давайте представим что подключение к БД у вас занимает 1 секунду, тогда каждый ваш запрос будет работать >1 секунды, если же вы подключитесь только один раз во время старта сервера, то все запросы уже эту секунду тратить не будут, так понятнее?
Кому проще, какой модуль, где вы его будете хранить? С диска что ли читать? Память между процессами разделять? Как состояние вы будете передавать между запросами? Вы вообще понимаете как это все внутри работает или лишь бы сморозить какую нибудь фигню?
Чем вам PHP то не угодил? И почему для вас сервер является чем то необычным, это обычный демон который на вход получает параметры, на выход отдает текст, примитивнейшая программа просто, которая сейчас реализуется несколькими строками кода на любом языке, где есть библиотека работы с сетью.
Для интерпретируемого языка это всё-равно бред.
И еще расскажите в чем разница интерпритированного языка и компилированного, когда и там и там код уж загружен в память полностью?
Вам пока далеко до осознания этого, не тот немного уровень =))
Суть в том что оно не очищается, это же сервер, который по вашим же словам должен постоянно работать, то есть его стартанули, он все инициализировал, к бд подключился и сидит ждет запросы
Не так, когда нибудь, может быть, если вы начнете читать документации, статьи, слушать конфы и сталкиваться с реально сложными проектами, где в лоб решения не работают, вот тогда возможно вы поймете как они сделали
Вообще стоило бы почитать прежде, чем писать, или это сильно сложно? =))) Но могу рассказать вкратце раз чтение документации и её осознание не сильная ваша сторона.
PHP создан чтобы умирать. Это значит что получив запрос, он пойдет распарсит файл (эту проблему закрыл opcache), далее загрузит в память нужный код, инициализирует окружение, подключится к БД, к кешеру и так далее, а вот дальше запустит запрос который выберет страничку и всю свою работу отчистит. Следущий запрос повторит тоже самое. Это, в том числе, делает таким как вы людям очень низкий порог входа в язык, вы не запариваетесь, делаете синглтоны, храните состояние в приложении и в целом пишите говнокод который все равно работает без утечек и багов потому что все окружение поднимается заново на каждый запрос, а в конце запроса очищается, но вот вся эта инициализация занимает большое количество, порой до 90%, времени и ресурсов у нормальных разработчиков и вот они придумали вот такие библиотеки, которые инициализируют код один раз, а дальше занимаются только обработкой запросов (полезными действиями)
Много статей на эту тему перечитал, но на счет выигрыша, на сколько я понял, вопрос относительный.
Покажите на простом и четком (житейском, так сказать) примере плюсы NGINX + PHP FPM по сравнению с nginx+apache+modphp
Так то зачем вам в этой связки апач? Уже же есть nginx, зачем 2 вебсервера то?На житейском к сожалению не могу показать, но если говорить прям очень кратко, апач сильнее утилизирует память, делает форки на каждый запрос и платите этим всего лишь за то чтобы иметь .htaccess с правилами реврайта, НО если вас устраивает производительность и поведение вашей связки, то вам конечно её менять не нужно
Что значит быстрее? Это связка более производительнее, не быстрее. То есть кпд выше.
Дело привычки, когда сам начинал было тяжко, как например перейти с винды на линукс (непривычно), когда привыкаешь конфиги пишутся быстро. Тем более основные конфиги собираются быстро, плюс есть всякие коллекции типа таких https://github.com/elasticweb/nginx-configs
Не используйте apache =)) связка nginx+php-fpm более производительная
Запрыгивай обратно =))
Но все равно не все там так гладко, но в целом да, очень перспективненько. Я так то пока больше изучаю Go, а в разрезе продакшена хочу попробовать https://roadrunner.dev/ затащить в один проект, мы как раз распиливаем монолит на битре (большой еком спорттоваров) на микросервисы в кубике, есть где попробовать