У меня под каждый сайт заводится отдельный пул, каждый пул запускат свои процессы под отдельным пользователем, но все пулы контролируются одним демоном. pm задаётся каждому пулу по обстоятельствам.

У меня под каждый сайт заводится отдельный пул, каждый пул запускат свои процессы под отдельным пользователем, но все пулы контролируются одним демоном. pm задаётся каждому пулу по обстоятельствам.

Спасибо за ответ. Именно так, я сейчас и делаю. Если минусы у данного метода? Что не устраивает? Сколько сайтов используеться? Рациональный ли такой подход в продакшене (на 100к уников в день не претендую, конечно же)?

100к уников в день — это чуть больше 1 rps. Это вообще не нагрузка, даже можно не тюнить ничего особо. Хотя интереснее пиковые значения, а не среднесуточные

100к уников в день — это чуть больше 1 rps. Это вообще не нагрузка, даже можно не тюнить ничего особо. Хотя интереснее пиковые значения, а не среднесуточные

Это в качестве примера было. Пока сервер стоит на локалхосте, а я изучаю основы веб серверов. Пытаюсь так сказать изучить все тонкости этого процесса. Вот и задумался как быть с пулами. Метод который описал MrClon кажеться довольно рациональным, его сообственно и использую. Вот только зоопарк из процессов кажеться весьма сомнительной затеей. Хотя если подумать, выбор не особо не велик. В любом случае для обеспечения работоспособности десятков хостов, потребуеться тратить ресурсы, вопрос только в том как делать это правильно.

У каждого метода есть как плюсы, так и минусы. Вот хотелось бы узнать несколько минусов у «зоопарка», если конечно такие есть.

100к уников в день — это чуть больше 1 rps.

Эм...не хочу показаться глупым, но раньше термина rps не встречал (кстати спасибо за это), гугл говорит следующее:

RPS — это количество запросов, получаемых фермой или сервером за одну секунду. Это общепринятая единица измерения нагрузки на сервер или ферму.

Так сколько же это 1 rps? ~100к? Есть все таки точное значение? Или же в данном контексте правильнее говорить 100 000 rps?

Это конфигурация из продакшена. Ну и из тестинга. Везде накатываю примерно одним скриптом (разными версиями, но архитектуру значимо я не пересматривал уже года три, только свистоперделки прикручивал).
На моём проекте используется штук 7 пулов на сервере. У одного клиента 37 пулов в php 7.0 и 7 в 5.6 (легаси такое легаси), это два независимых php-fpm демона. Нагрузка не равномерна. 80 запросов приходится на 20 процентов сайтов (это в лучшем случае).
Минусы? Ну ХЗ. Теоретически не очень кошерно что нельзя перезапустить только один пул (хотя может и есть способ). При наличии opcache, и учитывая что он сбрасывается при рестарте php-fpm, под большой нагрузкой не хотелось-бы перезапускать все пулы из-за мелочи. Но мне это не настолько актуально что-бы начать как-то чесаться.

Сам себя поправлю. Не сообразил сразу.

100к уников В ДЕНЬ (!!!)

RPS — это количество запросов, получаемых фермой или сервером за ОДНУ СЕКУНДУ (!!!)

Теперь мне понятно, что ты хотел сказать.

Минусы? Ну ХЗ. Теоретически не очень кошерно что нельзя перезапустить только один пул (хотя может и есть способ).

Можно конечно прибить kill-ом, он перезапуститься, только уверен, что это вовсе неправильно. Но как вариант :)

Но мне это не настолько актуально что-бы начать как-то чесаться.

Да, ты прав. Значит буду использовать данный метод. Спасибо)

А чем тебе не угодил зоопарк процессов? Чего их экономить.
Вариантов три:
1) Свалить всё в один пул. Никакой изоляции сайтов, за то можно задать общий лимит воркеров и всё такое.
2) Один демон на много пулов. Сайты изолированы, можно их отдельно конфигурировать.
3) Много демонов по одному пулу в каждом. То-же самое, только добавляется табун демонов. В каких-то случаях это может быть удобнее, в каких-то наоборот.

Можно конечно прибить kill-ом

Все воркеры данного пула (которые постоянно запускаются). И я сомневаюсь что воркеры при старте читают конфиг своего пула, скорее его читает демон-контроллер (который один на все пулы), хранит в памяти и запускает новые воркеры сообразно этому конфигу.

В любом случае в проде сейчас у меня зачастую используется политика управления воркерами ondemand, из-за жёсткой нехватки памяти, так-что воркеры долго не живут.

А чем тебе не угодил зоопарк процессов? Чего их экономить.

Я так понимаю если обращение к пулу не происходит, ресурсы на обработку пула не затрагиваются?
Или же выделяеться n-ое количество тех самых ресурсов, в зависимости от конфигурации этого же пула?
Ведь если на одном из хостов обработка php не происходит, зачем тогда тратить ресурсы на поддержание жизни пула?

Или мне идти перечитывать маны?)

В любом случае в проде сейчас у меня зачастую используется политика управления воркерами ondemand

Вот как раз про ondemand хотел написать, при его использовании создаеться пул, только если в нем есть необходимость, а дальше после обработки он прекращает свое существование?

Из вики:

ondemand - число процессов, порождающихся по требованию (когда появляются запросы, в отличии от опции dynamic, когда стартует определенное количество процессов, равное pm.start_servers, вместе с запуском службы.

Я все правильно понял?

P.S перечитав про dynamic, пришел к выводу, что система выделяет некоторое значение ресурсов изходя из настроек пула, если их (ресурсов) не хватает, то они автоматически увеличиваються, а после выполнения поставленных операций возвращаються к своему изначальному значению. Все верно? Или попить кофе и перечитать еще раз?)

Если я все правильно «вкурил», то метод ondemand очень хорошая политика для управления воркерами, и смысла использовать dynamic нету, только если у тебя один хост (с динамическим контентом), и ты не хочешь тратить время на «порождение» тех самых процессов.

Во-первых пул это просто набор процессов. Это не какой-то отдельный процесс.
При политике ondemand воркеры создаётся только тогда когда приходит запрос. Через несколько секунд (задаётся в настройках) после завершения обработки запроса (если не поступит нового запроса который можно передать воркеру) воркер убивается.
При dynamic демон всегда поддерживает некоторое заданное количество воркеров в пуле, и распределяет запросы между ними. Если для обработки запросов не хватает воркеров то демон создаёт дополнительных (вплоть до некоторого конфигурируемого значения). Когда потребность в дополнительных воркерах отпадает демон убивает лишние, так что-бы осталось нужное количество.
Профит от повторного использования воркеров в том что не тратится время на повторное создание процесса. Но если у тебя тормозной код то на его фоне ты этого времени всё-равно не заметишь.
На сколько я понимаю это происходит как-то так.

Попаболь в том что воркеры не особо спешат освобождать память использованную для обработки запроса (кстати я не в курсе баг это или какая-то непонятная фича). По этому если твоё приложение на обработку каждого запроса тратит (например) 100 мб памяти и у тебя есть 3 воркера, каждый из которых за свою жизнь получил хотя-бы один запрос, то у тебя в системе будет висеть три процесса каждый из которых выжирает по 100 мб памяти, даже если запросов в тот пул сейчас нет вообще. Побаболь наступает тогда когда у тебя есть куча малопосещаемых сайтов с жадным до памяти кодом.

У меня используется dynamic для пулов которые без запросов не остаются, и ondemand для малопосещаемых сайтов.

Ага, свои ошибки понял. Теперь все более менее ясно. Спасибо!