Когда уже сделают сабж? Здесь http://php-fpm.org/What_is_PHP-FPM
Dynamic number of processes, depending on the load TODO
Сделайте же, очень надо!

2009/10/17 ArtemZ <zhirkow@gmail.com>:
> Когда уже сделают сабж? Здесь http://php-fpm.org/What_is_PHP-FPM
> Dynamic number of processes, depending on the load     TODO
> Сделайте же, очень надо!

а зачем?



--

wbr,
fisher

Alexey A. Rybak wrote:
> 2009/10/17 ArtemZ <zhirkow@gmail.com>:
>> Когда уже сделают сабж? Здесь http://php-fpm.org/What_is_PHP-FPM
>> Dynamic number of processes, depending on the load TODO
>> Сделайте же, очень надо!
> а зачем?
К апачу привыкли :-)
Вообще, разные бывают случаи... Мы в своей софтинке сделали это
управляемым через сигналы мастеру: kill -USR1 увеличивает количество
worker'ов на N, kill -USR2 - уменьшает.

Что значит зачем? У меня есть сервер, на нём 300 пользователей. Для
каждого пользователя запускается отдельный бэкенд. Если нет
динамического расширения кол-ва процессов, значит мне для каждого
пользователя придётся запускать стандартное кол-во процессов.
Например, стандартно будет 10. 300 на 10 = 3000! Лучше было бы
запускать по умолчанию 1 процесс на пользователя и по мере надобности
расширять бекэнд для грузящих пользователей.
апач не предлагать.

On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>
> > Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
> > Dynamic number of processes, depending on the load     TODO
> > Сделайте же, очень надо!
>
> а зачем?
>
> --
>
> wbr,
> fisher

2009/10/18 ArtemZ <zhirkow@gmail.com>:
> Что значит зачем? У меня есть сервер, на нём 300 пользователей. Для
> каждого пользователя запускается отдельный бэкенд. Если нет
> динамического расширения кол-ва процессов, значит мне для каждого
> пользователя придётся запускать стандартное кол-во процессов.
> Например, стандартно будет 10. 300 на 10 = 3000! Лучше было бы
> запускать по умолчанию 1 процесс на пользователя и по мере надобности
> расширять бекэнд для грузящих пользователей.
> апач не предлагать.

хозяин - барин, но думаю, что 300 пулов - плохо при любом раскладе,
динамически они будут расширяться или нет.
если вы готовы выступить спонсором фичи - можете обратиться к майклу.
насколько я понимаю, в ближайших планах этой фичи нет.
она висит в таком "заявленном" виде уже третий или четвертый год.
можете попробовать схитрить - автоматически анализировать загрузку,
менять конфиг и делать время от времени плавный перезапуск. но в любом
случае 300 пулов на сервер - это слишком много.

>
> On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
>> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>>
>> > Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
>> > Dynamic number of processes, depending on the load     TODO
>> > Сделайте же, очень надо!
>>
>> а зачем?

--

wbr,
fisher

On Sunday 18 October 2009 21:15, Alexey A. Rybak wrote:
> 2009/10/18 ArtemZ <zhirkow@gmail.com>:
> > Что значит зачем? У меня есть сервер, на нём 300 пользователей. Для
> > каждого пользователя запускается отдельный бэкенд. Если нет
> > динамического расширения кол-ва процессов, значит мне для каждого
> > пользователя придётся запускать стандартное кол-во процессов.
> > Например, стандартно будет 10. 300 на 10 = 3000! Лучше было бы
> > запускать по умолчанию 1 процесс на пользователя и по мере надобности
> > расширять бекэнд для грузящих пользователей.
> > апач не предлагать.
>
> хозяин - барин, но думаю, что 300 пулов - плохо при любом раскладе,
> динамически они будут расширяться или нет.
> если вы готовы выступить спонсором фичи - можете обратиться к майклу.
> насколько я понимаю, в ближайших планах этой фичи нет.
> она висит в таком "заявленном" виде уже третий или четвертый год.
> можете попробовать схитрить - автоматически анализировать загрузку,
> менять конфиг и делать время от времени плавный перезапуск. но в любом
> случае 300 пулов на сервер - это слишком много.

Дело было так: php-fpm создавался для случаев когда сайт один, а физических
серверов много. В этой схеме сайту не нужно делиться ресурсами с другими
сайтами. И константное число воркеров полезно: я подал нагрузку и выявил, что
больше 80 воркеров параллельно работают плохо, поставил цифру 80 в конфиге и
забыл.

В случае с масс хостингом ситуация наоборот - сервер один а сайтов много. И
понятно, что честное распределение ресурсов было бы немного проще, будь у
php-fpm динамическое число воркеров.

PS. Это я ответил на вопрос "Что значит зачем?" :-)


> > On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
> >> 2009/10/17 ArtemZ <zhir...@gmail.com>:
> >> > Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
> >> > Dynamic number of processes, depending on the load     TODO
> >> > Сделайте же, очень надо!
> >>
> >> а зачем?

--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

Здравствуйте.

300 пулов - плохо при любом раскладе?
а как же шаред?
300 пулов с не очень ресурсоемкими сайтами вытянет сервер думаю не
особо парясь

почему же тогда много?

> 2009/10/18 ArtemZ <zhirkow@gmail.com>:
>> Что значит зачем? У меня есть сервер, на нём 300 пользователей. Для
>> каждого пользователя запускается отдельный бэкенд. Если нет
>> динамического расширения кол-ва процессов, значит мне для каждого
>> пользователя придётся запускать стандартное кол-во процессов.
>> Например, стандартно будет 10. 300 на 10 = 3000! Лучше было бы
>> запускать по умолчанию 1 процесс на пользователя и по мере надобности
>> расширять бекэнд для грузящих пользователей.
>> апач не предлагать.

> хозяин - барин, но думаю, что 300 пулов - плохо при любом раскладе,
> динамически они будут расширяться или нет.
> если вы готовы выступить спонсором фичи - можете обратиться к майклу.
> насколько я понимаю, в ближайших планах этой фичи нет.
> она висит в таком "заявленном" виде уже третий или четвертый год.
> можете попробовать схитрить - автоматически анализировать загрузку,
> менять конфиг и делать время от времени плавный перезапуск. но в любом
> случае 300 пулов на сервер - это слишком много.

>>
>> On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
>>> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>>>
>>> > Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
>>> > Dynamic number of processes, depending on the load     TODO
>>> > Сделайте же, очень надо!
>>>
>>> а зачем?

ArtemZ пишет:
> Что значит зачем? У меня есть сервер, на нём 300 пользователей.
> апач не предлагать.
>
и чем же вам плох апач? для шареда это самое оно. 300 редкопосещаемых
юзеров.
зачем е...ть себе мозги?

> On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
>
>> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>>
>>
>>> Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
>>> Dynamic number of processes, depending on the load TODO
>>> Сделайте же, очень надо!
>>>
>> а зачем?
>>
>> --
>>
>> wbr,
>> fisher

Апач очень плохо для шареда, нет, действительно очень плохо. Апач -
сборище свистоперделок, он не умеет нативно ограничивать скорость
передачи данных, не умеет ограничивать кол-во соединений на
виртуальный хост. А использование модулей апача для этого - это мрак,
вся эта телега будет дохрена жрать ресурсов, даже больше, чем
пользователь, которого мы пытаемся ограничить, при этом эффективность
ограничений будет весьма сомнительна. Ну и в апаче тупая модель
обработки соединений. Впрочем, последнее не мои слова. Вообще,
поспрашивайте людей, почему они ставят nginx как фронтэнд к апачу. Да
просто напросто потому, что он РУЛИТ. Безотказно и безоговорочно.
Вообще, я не собираюсь с вами об этом спорить. Я лишь хочу, чтобы в
php-fpm сделали нужную мне фичу, возможно я буду готов заплатить, если
мне не удастся сделать эту фичу самостоятельно и вообще без php-fpm

On Oct 19, 4:03 pm, Sergej Kandyla <sk.p...@gmail.com> wrote:
> ArtemZ пишет:> Что значит зачем? У меня есть сервер, на нём 300 пользователей.
> > апач не предлагать.
>
> и чем же вам плох апач? для шареда это самое оно. 300 редкопосещаемых
> юзеров.
> зачем е...ть себе мозги?
>
> > On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
>
> >> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>
> >>> Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
> >>> Dynamic number of processes, depending on the load     TODO
> >>> Сделайте же, очень надо!
>
> >> а зачем?
>
> >> --
>
> >> wbr,
> >> fisher
>
>

19.10.2009 16:54, ArtemZ wrote:
> Апач очень плохо для шареда, нет, действительно очень плохо.
Расскажите это клиентам с реврайтами и прочими apache-only хинтами в
..htaccess.

а еще лучше - разработчикам апача :)

20 октября 2009 г. 16:49 пользователь Alex Vorona <vorona.al@gmail.com>написал:

>
> 19.10.2009 16:54, ArtemZ wrote:
>
>> Апач очень плохо для шареда, нет, действительно очень плохо.
>>
> Расскажите это клиентам с реврайтами и прочими apache-only хинтами в
> .htaccess.
>



--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com

2009/10/19 ArtemZ <zhirkow@gmail.com>:
> Апач очень плохо для шареда, нет, действительно очень плохо. Апач -
> сборище свистоперделок, он не умеет нативно ограничивать скорость
> передачи данных, не умеет ограничивать кол-во соединений на
> виртуальный хост. А использование модулей апача для этого - это мрак,
> вся эта телега будет дохрена жрать ресурсов, даже больше, чем
> пользователь, которого мы пытаемся ограничить, при этом эффективность
> ограничений будет весьма сомнительна. Ну и в апаче тупая модель
> обработки соединений. Впрочем, последнее не мои слова. Вообще,
> поспрашивайте людей, почему они ставят nginx как фронтэнд к апачу. Да
> просто напросто потому, что он РУЛИТ. Безотказно и безоговорочно.
> Вообще, я не собираюсь с вами об этом спорить. Я лишь хочу, чтобы в
> php-fpm сделали нужную мне фичу, возможно я буду готов заплатить, если
> мне не удастся сделать эту фичу самостоятельно и вообще без php-fpm

даю наводку - Вам никто не предлагал ставить апач фронтендом ;)

--

wbr,
fisher

Люди, говорящие, что апач - это очень плохо для шареда, скорее всего,
просто не умеют настроить апач для шареда O:-)

В любом случае, выполнение php распараллелить не удастся, всегда на 1
запрос будет уходить 1 процесс, и от этого никуда не деться. С
apache-like управлением воркерами эти процессы еще и будут постоянно
умирать/форкаться, на что и будет тратиться достаточно большая часть
ресурсов.

А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
придется висеть для каждого юзера и форкаться при запросе.

19 октября 2009 г. 17:54 пользователь ArtemZ <zhirkow@gmail.com> написал:
> Апач очень плохо для шареда, нет, действительно очень плохо. Апач -
> сборище свистоперделок, он не умеет нативно ограничивать скорость
> передачи данных, не умеет ограничивать кол-во соединений на
> виртуальный хост. А использование модулей апача для этого - это мрак,
> вся эта телега будет дохрена жрать ресурсов, даже больше, чем
> пользователь, которого мы пытаемся ограничить, при этом эффективность
> ограничений будет весьма сомнительна. Ну и в апаче тупая модель
> обработки соединений. Впрочем, последнее не мои слова. Вообще,
> поспрашивайте людей, почему они ставят nginx как фронтэнд к апачу. Да
> просто напросто потому, что он РУЛИТ. Безотказно и безоговорочно.
> Вообще, я не собираюсь с вами об этом спорить. Я лишь хочу, чтобы в
> php-fpm сделали нужную мне фичу, возможно я буду готов заплатить, если
> мне не удастся сделать эту фичу самостоятельно и вообще без php-fpm
>
> On Oct 19, 4:03 pm, Sergej Kandyla <sk.p...@gmail.com> wrote:
>> ArtemZ пишет:> Что значит зачем? У меня есть сервер, на нём 300 пользователей.
>> > апач не предлагать.
>>
>> и чем же вам плох апач? для шареда это самое оно. 300 редкопосещаемых
>> юзеров.
>> зачем е...ть себе мозги?
>>
>> > On Oct 17, 11:43 pm, "Alexey A. Rybak" <alexey.ry...@gmail.com> wrote:
>>
>> >> 2009/10/17 ArtemZ <zhir...@gmail.com>:
>>
>> >>> Когда уже сделают сабж? Здесьhttp://php-fpm.org/What_is_PHP-FPM
>> >>> Dynamic number of processes, depending on the load     TODO
>> >>> Сделайте же, очень надо!
>>
>> >> а зачем?
>>
>> >> --
>>
>> >> wbr,
>> >> fisher
>>
>>



--
С уважением, Борис Долгов.
icq 77556665
e-mail boris@dolgov.name

20.10.2009 16:04, Борис Долгов wrote:
> А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
> придется висеть для каждого юзера и форкаться при запросе.
>
Можно висеть от рута 1-м процессом и форкаться в юзера при
запросе(юзера:группу передавать через fastcgi_param)

Alex Vorona пишет:
>
> 20.10.2009 16:04, Борис Долгов wrote:
>> А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
>> придется висеть для каждого юзера и форкаться при запросе.
>>
> Можно висеть от рута 1-м процессом и форкаться в юзера при
> запросе(юзера:группу передавать через fastcgi_param)

это что, конкурс извращенных вариантов? ;)

20.10.2009 16:53, Sergej Kandyla wrote:
>
> Alex Vorona пишет:
>> 20.10.2009 16:04, Борис Долгов wrote:
>>> А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
>>> придется висеть для каждого юзера и форкаться при запросе.
>>>
>> Можно висеть от рута 1-м процессом и форкаться в юзера при
>> запросе(юзера:группу передавать через fastcgi_param)
> это что, конкурс извращенных вариантов? ;)
>
Нет, просто оффтоп о реализации враппера.

Опасно. Да и не в том суть, сколько будут висеть, а в fork/process per
request :-)

20 октября 2009 г. 17:40 пользователь Alex Vorona <vorona.al@gmail.com> написал:
>
> 20.10.2009 16:04, Борис Долгов wrote:
>>
>> А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
>> придется висеть для каждого юзера и форкаться при запросе.
>>
>
> Можно висеть от рута 1-м процессом и форкаться в юзера при
> запросе(юзера:группу передавать через fastcgi_param)
>



--
С уважением, Борис Долгов.
icq 77556665
e-mail boris@dolgov.name

20.10.2009 16:57, Борис Долгов wrote:
> Опасно. Да и не в том суть, сколько будут висеть, а в fork/process per
> request :-)
>
> 20 октября 2009 г. 17:40 пользователь Alex Vorona <vorona.al@gmail.com> написал:
>
>> 20.10.2009 16:04, Борис Долгов wrote:
>>
>>> А еще Вы не сможете пускать CGI-скрипты без враппера, которому тоже
>>> придется висеть для каждого юзера и форкаться при запросе.
>>>
>>>
>> Можно висеть от рута 1-м процессом и форкаться в юзера при
>> запросе(юзера:группу передавать через fastcgi_param)
>>
>>
Тяжёлый я так понимаю не сам fork per request, а непосредсвенно exec
cgi-приложения, от которого уже не уйдёшь.
Пока я не нашёл как запустить процесс из-под себя без fork/аналогов, с
перенаправлением stdin&stdout. Похоже, что без fork на запрос в cgi
просто не обойтись. Потрейсил апач - при запуске cgi тоже форкается.