Хороший комментарий на мой взгляд, добавлю немного своего:
Главная проблема PHP на мой взгляд, это почти нулевая стоимость входа, люди нахватаются, он им все прощает, делают ошибки и считают что в этом проблема языка, а не их и кидаются изучать другой язык.
Много комментариев к данной статье, не все лестные. Скажу за себя — добавил данную статью в любимые статьи на хабре! Может быть и банально все и т.п. НО, человек озвучил мысли, поделился своими мыслями, что дало возможность сравнить свои мысли с его мышлением и опытом. Более того, как это часто бывает, все всё знают, все умные, но когда доходит до обсуждения, то оказывается все думают по разному и часто вообще черт знает что, поэтому такие статьи полезны чтобы зафиксировать свои убеждения и чтобы у других так же это произошло и небыло разнобоя в понимании всего этого.
Вот здесь написано, что синтаксис еще будет осуджаться и есть предложение сделать через @
Since syntax is by far the most discussed point about this RFC, we also thought of an alternative by introducing a new token for attributes (T_ATTRIBUTE) defined as @: that the parser could look for. Choice of syntax will be a secondary vote on the RFC.
“The “Smiley” syntax uses the shorter, more familiar “at” symbol commonly seen in docblocks. The downside is that it does not permit whitespace in attribute names to allow detecting the ending of the declaration.”
Т.е. сервер RoadRunner который написан на Go запускает PHP интерпритатор который установлен на машине где он запускается? Т.е. если я в конце года, когда выйдет PHP8, установлю новый php и RoadRunner будет с ним работать, но код так же должен быть написан на php8, а фреймворк spiral может отвалиться т.к. он написан под php7?
Добрый день.
Не нашел в обсуждениии, но очень интересно — в 20 году планируется выход PHP8, RoadRunner и Spiral будут с ним работать? Наверное больше интересует будет ли корректно взаимодействовать RoadRunner с кодом на PHP8?
Наверное Вам ответят еще представители разработчиков RR, у меня пока у самого вопросов хватает, но как понял:
Если по простому то да, это аналогия, отличие в том, что fpm хранит пул только процессов php, далее идет обычный алгоритм работы PHP (родился -> исполнился -> умер, и так каждый раз). RR же хранит в памяти пул процессов с уже загруженными, интерпретированными и транслированными данными скриптов в байт код. Т.е. весь код уже сидит в памяти (включая открытые ресурсы, подключения к БД, открытые файлы и т.п.), интерпритатору только остается его исполнить (родился -> исполнился -> ожидает следующего обращения к воркеру вися в памяти). НО естественно и написание кода должно быть уже другим, т.к. все инициализированные переменные, все открытые ресурсы, остаются в памяти, т.е. их надо очищать (на ваше усмотрение конечно закрывать ли открытые ресурсы, подключения к БД и т.п.), иначе при следующем обращении к воркеру в них уже будут данные.
Мои вопросы представителям разработчиков RR:
1. Корректно ли я описал RR?
2. Какое количество воркеров рекомендуется создавать т.е. от чего это зависит, на что обращать внимание?
Спасибо!
Добрый день.
Был участником, но уже после PHP Meetup #3, немного осмыслив что к чему, у меня возник вопрос по RoadRunner, буду благодарен если ответите на него или дадите ссылку где почитать. Спасибо!
К примеру у нас на сервер идет 1000 обращений в секунду, RoadRunner обслуживает 10 воркеров, время исполнения кода одного воркера 500мс (цифры условные, взяты из головы), т.е. в секунду полноценно обработать можем только 20 запросов. Что происходит с остальными 980 запросами?
Запросы выстраиваются в очередь в RoadRunner? Или идет переключение контента и один воркер разом может обрабатывать 100 запросов.
Если идет переключение контента, то возникает много других вопросов. К примеру в какой момент какое состояние будет у исполняемого скрипта? Кто отвечает за переключение контента, диспетчер задач Go или PHP интерпретатор отдает это на откуп операционной системе (правда это уже из области многопоточности и асинхронности)
Главная проблема PHP на мой взгляд, это почти нулевая стоимость входа, люди нахватаются, он им все прощает, делают ошибки и считают что в этом проблема языка, а не их и кидаются изучать другой язык.
Вторая проблема PHP — люди не хотят глубоко вникать в него, например недавно столкнулся с человеком который считает что yild есть в phyton и нет в php. А вы знаете, что генераторы появились еще в PHP5.5? Вот статья интересная — nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html
Не нашел в обсуждениии, но очень интересно — в 20 году планируется выход PHP8, RoadRunner и Spiral будут с ним работать? Наверное больше интересует будет ли корректно взаимодействовать RoadRunner с кодом на PHP8?
Если по простому то да, это аналогия, отличие в том, что fpm хранит пул только процессов php, далее идет обычный алгоритм работы PHP (родился -> исполнился -> умер, и так каждый раз). RR же хранит в памяти пул процессов с уже загруженными, интерпретированными и транслированными данными скриптов в байт код. Т.е. весь код уже сидит в памяти (включая открытые ресурсы, подключения к БД, открытые файлы и т.п.), интерпритатору только остается его исполнить (родился -> исполнился -> ожидает следующего обращения к воркеру вися в памяти). НО естественно и написание кода должно быть уже другим, т.к. все инициализированные переменные, все открытые ресурсы, остаются в памяти, т.е. их надо очищать (на ваше усмотрение конечно закрывать ли открытые ресурсы, подключения к БД и т.п.), иначе при следующем обращении к воркеру в них уже будут данные.
Мои вопросы представителям разработчиков RR:
1. Корректно ли я описал RR?
2. Какое количество воркеров рекомендуется создавать т.е. от чего это зависит, на что обращать внимание?
Спасибо!
Был участником, но уже после PHP Meetup #3, немного осмыслив что к чему, у меня возник вопрос по RoadRunner, буду благодарен если ответите на него или дадите ссылку где почитать. Спасибо!
К примеру у нас на сервер идет 1000 обращений в секунду, RoadRunner обслуживает 10 воркеров, время исполнения кода одного воркера 500мс (цифры условные, взяты из головы), т.е. в секунду полноценно обработать можем только 20 запросов. Что происходит с остальными 980 запросами?
Запросы выстраиваются в очередь в RoadRunner? Или идет переключение контента и один воркер разом может обрабатывать 100 запросов.
Если идет переключение контента, то возникает много других вопросов. К примеру в какой момент какое состояние будет у исполняемого скрипта? Кто отвечает за переключение контента, диспетчер задач Go или PHP интерпретатор отдает это на откуп операционной системе (правда это уже из области многопоточности и асинхронности)