Comments 6
Добрый день.
Был участником, но уже после PHP Meetup #3, немного осмыслив что к чему, у меня возник вопрос по RoadRunner, буду благодарен если ответите на него или дадите ссылку где почитать. Спасибо!
К примеру у нас на сервер идет 1000 обращений в секунду, RoadRunner обслуживает 10 воркеров, время исполнения кода одного воркера 500мс (цифры условные, взяты из головы), т.е. в секунду полноценно обработать можем только 20 запросов. Что происходит с остальными 980 запросами?
Запросы выстраиваются в очередь в RoadRunner? Или идет переключение контента и один воркер разом может обрабатывать 100 запросов.
Если идет переключение контента, то возникает много других вопросов. К примеру в какой момент какое состояние будет у исполняемого скрипта? Кто отвечает за переключение контента, диспетчер задач Go или PHP интерпретатор отдает это на откуп операционной системе (правда это уже из области многопоточности и асинхронности)
Запросы выстраиваются в очередь в RoadRunner?

Да, запросы находятся в ожидании. Контекст не переключается что гарантирует что ваш PHP скрипт работает в однопоточном режиме.

Правильно понимаю, что 1 воркер — это довольно полная аналогия php-fpm?
Или все же fpm плодит процессы, а воркер RR работает только с одним процессом?
Наверное Вам ответят еще представители разработчиков RR, у меня пока у самого вопросов хватает, но как понял:
Если по простому то да, это аналогия, отличие в том, что fpm хранит пул только процессов php, далее идет обычный алгоритм работы PHP (родился -> исполнился -> умер, и так каждый раз). RR же хранит в памяти пул процессов с уже загруженными, интерпретированными и транслированными данными скриптов в байт код. Т.е. весь код уже сидит в памяти (включая открытые ресурсы, подключения к БД, открытые файлы и т.п.), интерпритатору только остается его исполнить (родился -> исполнился -> ожидает следующего обращения к воркеру вися в памяти). НО естественно и написание кода должно быть уже другим, т.к. все инициализированные переменные, все открытые ресурсы, остаются в памяти, т.е. их надо очищать (на ваше усмотрение конечно закрывать ли открытые ресурсы, подключения к БД и т.п.), иначе при следующем обращении к воркеру в них уже будут данные.
Мои вопросы представителям разработчиков RR:
1. Корректно ли я описал RR?
2. Какое количество воркеров рекомендуется создавать т.е. от чего это зависит, на что обращать внимание?
Спасибо!

Привет, описание корректное.


Количество воркеров зависит напрямую от нагрузки на систему и количество времени который воркер проводит в IO-wait. Т.е. например если ваш ПХП код выполняется без внешних ресурсов за 0.01мс то вам хватит воркеров по количеству ядер. Если же коду требуется что-то записать в сокет/файл и задача уже "зависает" на 10мс то количество воркеров стоит поднимать эмпирически.


Фактически вся работа по оптимизации кода для roadrunner заключается в выносе тяжелых операций в фон — чтобы не блокировать http воркеры.


Действительно, при разработке приложения стоит учитывать что все остается в памяти. Но это не такая уж и сложная задача если у вас есть правильно настроенный фреймворк.

RR работает с несколькими процессами, разница в том что процессы лучше утилизируются за счет использования RAM по ее прямому назначению.

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 January 2006

Location

Россия

Website

badoo.com

Employees

201–500 employees

Registered

15 December 2009

Habr blog