2011/7/9 grigori <grigori.kochanov@gmail.com>:
>
>
> On 9 июл, 14:52, Troll <trollofdarkn...@gmail.com> wrote:
>> If you have 200 websites accessed 1 time/minute, it will depend on your
>> configuration :
>>
>> expiration time < 1 min -> processes will die and then be reborn next minute
>> expiration time > 1 min -> processes will never end because they will
>> receive a request before the expiration time, and it will reset the
>> expiration time (since we're talking here about spare time).
>
> Which means the rarely-served sites get deadlocked by the more popular
> ones.
>
>
>> So in any case, imho, you will get a high number of php processes in
>> memory. But try to do that with CGI and I think your server will just
>> fall down (the hard disk at first maybe) since it would be launching
>> around 200 new process more or less constantly.
>
> With CGI and mod_php you get predictable results at least, without
> race conditions.
>
>
>> then some requests will queue, the response time will be higher than
>> with a fpm use, but less memory would be used (not really sure in fact,
>> because if we then compare apache vs. nginx, you will in fact get 200
>> apache2 process
> the requests will either be queued, or we get 200 processes;
> in reality, we don't run more then 100 children in apache
>
>> which will get each own some memoery,
> but will switch context without restarting
>
>
> The patch solves a problem for the non-visited sites only.
> With almost any load like one request per minute for hundreds of sites
> the economy on re-starting may take you into a race condition with
> locking parts of the sites out, the small expiration time makes you a
> CGI server.
>

you are right about the small expiration time which makes act almost
like a CGI server.

the ondemand mode can only answer to several cases. not all of them.

Your case has already been discussed several times. In a perfect
world, you're looking for:
1- you 700 websites, each running on a different user (security reason)
2- you want to reuse processes in order to prevent memory and cpu
consumption. I mean, the process P1 will first handle a request for
site #1 (with user #1) and then handle a request for site #2 (with
user #2)

In fact this is not possible for security reasons. Once a process has
forked, it's switched to one user (man 2 setuid) and it cannot switch
back to another user. So your process is stuck to run unprivilege.

I'm aware of this need and I'm still looking for a solution to handle
it which will keep security.

But if you have ideas, you're welcome to propose them here :)

++ Jerome

Here are links to old discussions I mentioned

http://groups.google.com/group/highload-php-en/browse_thread/thread/70450f63a727ffd3/70994c7261875664
http://groups.google.com/group/highload-php-en/browse_thread/thread/40c1db464bb5e714/7c4c6a1a449808c9

Le 9 juillet 2011 14:17, Jérôme Loyet <ml@fatbsd.com> a écrit :
> 2011/7/9 grigori <grigori.kochanov@gmail.com>:
>>
>>
>> On 9 июл, 14:52, Troll <trollofdarkn...@gmail.com> wrote:
>>> If you have 200 websites accessed 1 time/minute, it will depend on your
>>> configuration :
>>>
>>> expiration time < 1 min -> processes will die and then be reborn next minute
>>> expiration time > 1 min -> processes will never end because they will
>>> receive a request before the expiration time, and it will reset the
>>> expiration time (since we're talking here about spare time).
>>
>> Which means the rarely-served sites get deadlocked by the more popular
>> ones.
>>
>>
>>> So in any case, imho, you will get a high number of php processes in
>>> memory. But try to do that with CGI and I think your server will just
>>> fall down (the hard disk at first maybe) since it would be launching
>>> around 200 new process more or less constantly.
>>
>> With CGI and mod_php you get predictable results at least, without
>> race conditions.
>>
>>
>>> then some requests will queue, the response time will be higher than
>>> with a fpm use, but less memory would be used (not really sure in fact,
>>> because if we then compare apache vs. nginx, you will in fact get 200
>>> apache2 process
>> the requests will either be queued, or we get 200 processes;
>> in reality, we don't run more then 100 children in apache
>>
>>> which will get each own some memoery,
>> but will switch context without restarting
>>
>>
>> The patch solves a problem for the non-visited sites only.
>> With almost any load like one request per minute for hundreds of sites
>> the economy on re-starting may take you into a race condition with
>> locking parts of the sites out, the small expiration time makes you a
>> CGI server.
>>
>
> you are right about the small expiration time which makes act almost
> like a CGI server.
>
> the ondemand mode can only answer to several cases. not all of them.
>
> Your case has already been discussed several times. In a perfect
> world, you're looking for:
> 1- you 700 websites, each running on a different user (security reason)
> 2- you want to reuse processes in order to prevent memory and cpu
> consumption. I mean, the process P1 will first handle a request for
> site #1 (with user #1) and then handle a request for site #2 (with
> user #2)
>
> In fact this is not possible for security reasons. Once a process has
> forked, it's switched to one user (man 2 setuid) and it cannot switch
> back to another user. So your process is stuck to run unprivilege.
>
> I'm aware of this need and I'm still looking for a solution to handle
> it which will keep security.
>
> But if you have ideas, you're welcome to propose them here :)
>
> ++ Jerome
>

> you are the only one who can tell if you can test new stuff on your
> production server :) I can't make that call for you
This was to explain my question about (minimum) stability :)

If 5.3 branch only receives bugfixes, I'll try the switch. I'll tell you
so. Thank you for the information.

Regards,
Troll



On 07/09/2011 01:57 PM, Jérôme Loyet wrote:
> 2011/7/9 Troll<trollofdarkness@gmail.com>:
>> By the way, about testing the patch, is the code directly taken from the SVN
>> repository (svn.php.net/viewvc/php/php-src/branches/PHP_5_3) stable enough ?
> 5.3 branch should only receives bugfixes so there is no reason not to
> be stable enough.
>
> But as it's not been released yet (we are in a RC stage), I can't guaranty it.
>
>> I'd like to test it& help its development, but currently don't have any
>> test server, only a production one :)
> you are the only one who can tell if you can test new stuff on your
> production server :) I can't make that call for you
>
>> Regards,
>> Troll
>>
>> On 07/09/2011 12:21 PM, Jérôme Loyet wrote:
>>> 2011/7/9 Troll<trollofdarkness@gmail.com>:
>>>> The patch has now been tested& validated ?
>>> I've tested it on my own and it needs to be tesed in order to be
>>> validated.
>>>
>>>> It's been a long time this feature request/patch has been waiting for an
>>>> interest (or maybe simply spare time) from the main tree developers, do
>>>> you
>>>> know why it has not been integrated yet in the main tree ?
>>> simply because it's not been tested. Help us testing it (and fix it if
>>> needed) and it integration into the sources will be much faster.
>>>
>>>> Everyone knows that this feature is expected from many many users in
>>>> order
>>>> to deploy FPM in shared hosting environment, I can't understand why it
>>>> has
>>>> not been put onto the priority list.
>>> It's all a matter of time. Don't forget it's opensource and based on
>>> voluntary participation
>>>
>>>> By the way :
>>>>
>>>> CGI/FastCGI with up to 1000 vhosts : http://www.legtux.org/phpinfo.php
>>>> It works better than mod_php as administrators.
>>>>
>>>> Romain
>>>>
>>>> Yes, but certainly not using a single pool / website. Maybe using only a
>>>> couple of pools with each of them handling hundreds of website (which
>>>> then
>>>> is similar to the use of mod_php, in a certain way). Or maybe using
>>>> ondemand
>>>> patch :)
>>>>
>>>> If the patch has been updated to the last sources, I'll certainly test
>>>> it. I
>>>> have to update my (compiled from sources) php version.
>>>>
>>>> But does the code directly taken from the SVN repository is stable enough
>>>> ?
>>>>
>>>>
>>>> Regards,
>>>> Troll
>>>>
>>>>
>>>> On 07/09/2011 02:26 AM, Jérôme Loyet wrote:
>>>>
>>>> for the record,
>>>>
>>>> I've just submit a small fix to the patch in order to correct the known
>>>> bug.
>>>>
>>>> ++ jerome
>>>>
>>>> PS: the patch can be found in https://bugs.php.net/bug.php?id=52569.
>>>>
>>>> Also note it should be applied on sources fetch from SVN:
>>>> fpm-ondemand.v8.patch on svn.php.net/viewvc/php/php-src/branches/PHP_5_4
>>>> fpm-ondemand.v8-5.3.patch on
>>>> svn.php.net/viewvc/php/php-src/branches/PHP_5_3
>>>>
>>>>
>>>> Le 9 juillet 2011 01:20, Jérôme Loyet<ml@fatbsd.com> a écrit :
>>>>
>>>> 2011/7/8 David Coallier<david@orchestra.io>:
>>>>
>>>> If you have some programming skills, I encourage you to take part in the
>>>> development of the "ondemand" patch. It has been tested and was, if I
>>>> remember well, nearly finished, but I think it was for an old FPM version
>>>> (in comparision to the current version) so the main task would be to
>>>> adapt
>>>> it to the last stable FPM version.
>>>>
>>>> Do you have a link to the ondemand patch?
>>>>
>>>> yes! https://bugs.php.net/bug.php?id=52569
>>>>
>>>> the patch have been updated for the last sources 2 days ago. You're
>>>> welcome to test it (even if there's still a bug I have to figure out).
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> David Coallier,
>>>> CTO Orchestra Platform Ltd, https://orchestra.io
>>>> @davidcoallier, skype://david.coallier
>>>>
>>>>

I tried the "ondemand" patch but I couldn't get it working. I posted
here : https://bugs.php.net/bug.php?id=52569&thanks=3
If someone has any idea :)

Regards,
Troll

On 07/09/2011 01:57 PM, Jérôme Loyet wrote:
> 2011/7/9 Troll<trollofdarkness@gmail.com>:
>> By the way, about testing the patch, is the code directly taken from the SVN
>> repository (svn.php.net/viewvc/php/php-src/branches/PHP_5_3) stable enough ?
> 5.3 branch should only receives bugfixes so there is no reason not to
> be stable enough.
>
> But as it's not been released yet (we are in a RC stage), I can't guaranty it.
>
>> I'd like to test it& help its development, but currently don't have any
>> test server, only a production one :)
> you are the only one who can tell if you can test new stuff on your
> production server :) I can't make that call for you
>
>> Regards,
>> Troll
>>
>> On 07/09/2011 12:21 PM, Jérôme Loyet wrote:
>>> 2011/7/9 Troll<trollofdarkness@gmail.com>:
>>>> The patch has now been tested& validated ?
>>> I've tested it on my own and it needs to be tesed in order to be
>>> validated.
>>>
>>>> It's been a long time this feature request/patch has been waiting for an
>>>> interest (or maybe simply spare time) from the main tree developers, do
>>>> you
>>>> know why it has not been integrated yet in the main tree ?
>>> simply because it's not been tested. Help us testing it (and fix it if
>>> needed) and it integration into the sources will be much faster.
>>>
>>>> Everyone knows that this feature is expected from many many users in
>>>> order
>>>> to deploy FPM in shared hosting environment, I can't understand why it
>>>> has
>>>> not been put onto the priority list.
>>> It's all a matter of time. Don't forget it's opensource and based on
>>> voluntary participation
>>>
>>>> By the way :
>>>>
>>>> CGI/FastCGI with up to 1000 vhosts : http://www.legtux.org/phpinfo.php
>>>> It works better than mod_php as administrators.
>>>>
>>>> Romain
>>>>
>>>> Yes, but certainly not using a single pool / website. Maybe using only a
>>>> couple of pools with each of them handling hundreds of website (which
>>>> then
>>>> is similar to the use of mod_php, in a certain way). Or maybe using
>>>> ondemand
>>>> patch :)
>>>>
>>>> If the patch has been updated to the last sources, I'll certainly test
>>>> it. I
>>>> have to update my (compiled from sources) php version.
>>>>
>>>> But does the code directly taken from the SVN repository is stable enough
>>>> ?
>>>>
>>>>
>>>> Regards,
>>>> Troll
>>>>
>>>>
>>>> On 07/09/2011 02:26 AM, Jérôme Loyet wrote:
>>>>
>>>> for the record,
>>>>
>>>> I've just submit a small fix to the patch in order to correct the known
>>>> bug.
>>>>
>>>> ++ jerome
>>>>
>>>> PS: the patch can be found in https://bugs.php.net/bug.php?id=52569.
>>>>
>>>> Also note it should be applied on sources fetch from SVN:
>>>> fpm-ondemand.v8.patch on svn.php.net/viewvc/php/php-src/branches/PHP_5_4
>>>> fpm-ondemand.v8-5.3.patch on
>>>> svn.php.net/viewvc/php/php-src/branches/PHP_5_3
>>>>
>>>>
>>>> Le 9 juillet 2011 01:20, Jérôme Loyet<ml@fatbsd.com> a écrit :
>>>>
>>>> 2011/7/8 David Coallier<david@orchestra.io>:
>>>>
>>>> If you have some programming skills, I encourage you to take part in the
>>>> development of the "ondemand" patch. It has been tested and was, if I
>>>> remember well, nearly finished, but I think it was for an old FPM version
>>>> (in comparision to the current version) so the main task would be to
>>>> adapt
>>>> it to the last stable FPM version.
>>>>
>>>> Do you have a link to the ondemand patch?
>>>>
>>>> yes! https://bugs.php.net/bug.php?id=52569
>>>>
>>>> the patch have been updated for the last sources 2 days ago. You're
>>>> welcome to test it (even if there's still a bug I have to figure out).
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> David Coallier,
>>>> CTO Orchestra Platform Ltd, https://orchestra.io
>>>> @davidcoallier, skype://david.coallier
>>>>
>>>>

I published a patch for FPM that could interest some of you, that allows
you to limit the total (no by pool, global) number of php processes in
memory.

I post it here on the list in case some people are interested in it :
https://bugs.php.net/bug.php?id=55166


Have a nice week-end.

Regards,
Troll

2011/7/9 Troll <trollofdarkness@gmail.com>:
> I published a patch for FPM that could interest some of you, that allows you
> to limit the total (no by pool, global) number of php processes in memory.
>
> I post it here on the list in case some people are interested in it :
> https://bugs.php.net/bug.php?id=55166

Hi

Thanks a lot for the patch. I'll look to it asap. New patches in 5.3
are freezed until 5.3.7 is out because we are in a RC release process.

++ Jerome

>
>
> Have a nice week-end.
>
> Regards,
> Troll
>

Nice feature!
Thank for your great work

On Sat, Jul 9, 2011 at 11:12 PM, Troll <trollofdarkness@gmail.com> wrote:

> I published a patch for FPM that could interest some of you, that allows
> you to limit the total (no by pool, global) number of php processes in
> memory.
>
> I post it here on the list in case some people are interested in it :
> https://bugs.php.net/bug.php?**id=55166https://bugs.php.net/bug.php?id=55166
>
>
> Have a nice week-end.
>
> Regards,
> Troll
>



--
Best regards,
Mr.Hien

http://www.mrhien.info

> Nice feature!
> Thank for your great work

As I said in the post on the bugtracker, this was actually not a lot of
work (only few changes), but I am pleased someone finds it useful. Thank
you for your "thank you" :)

> Hi
>
> Thanks a lot for the patch. I'll look to it asap. New patches in 5.3
> are freezed until 5.3.7 is out because we are in a RC release process.
>
> ++ Jerome
Ok, let me know !

Regards,
Troll

On 07/10/2011 05:50 PM, Mr. Hien wrote:
> Nice feature!
> Thank for your great work
>
> On Sat, Jul 9, 2011 at 11:12 PM, Troll <trollofdarkness@gmail.com
> <mailto:trollofdarkness@gmail.com>> wrote:
>
> I published a patch for FPM that could interest some of you, that
> allows you to limit the total (no by pool, global) number of php
> processes in memory.
>
> I post it here on the list in case some people are interested in
> it : https://bugs.php.net/bug.php?id=55166
>
>
> Have a nice week-end.
>
> Regards,
> Troll
>
>
>
>
> --
> Best regards,
> Mr.Hien
>
>

I do not have any follow-up.

As I understand, today we can't, with the last stable version of FPM,
manage many websites on one server.
So, how to use php with apache worker ?

FastCGI ?

Or else, with FPM, use one pool for all vhost, and define an
open_basedir variable like with mod_php. Is that feasible ? Is it secure ?

Thank,
Romain

2011/7/11 Romain <romain@kegtux.org>:
> I do not have any follow-up.
>
> As I understand, today we can't, with the last stable version of FPM, manage
> many websites on one server.
> So, how to use php with apache worker ?
>
> FastCGI ?
>
> Or else, with FPM, use one pool for all vhost, and define an open_basedir
> variable like with mod_php. Is that feasible ? Is it secure ?

it's feasible and secure as mod_php.

>
> Thank,
> Romain
>

> I do not have any follow-up.
>
> As I understand, today we can't, with the last stable version of FPM,
> manage many websites on one server.
> So, how to use php with apache worker ?
>
> FastCGI ?
>
> Or else, with FPM, use one pool for all vhost, and define an
> open_basedir variable like with mod_php. Is that feasible ? Is it secure ?


open_basedir kills the realpath_cache.
It's a negative performance impact :-(

Le 11/07/2011 16:17, Jérôme Loyet a écrit :
>> Or else, with FPM, use one pool for all vhost, and define an open_basedir
>> variable like with mod_php. Is that feasible ? Is it secure ?
> it's feasible and secure as mod_php.

But, I want use Apache Worker. Mod_php is not available in this mod.

Le 11/07/2011 16:23, rainer@ultra-secure.de a écrit :
> open_basedir kills the realpath_cache.
> It's a negative performance impact :-(

What to do then?

Romain

> Le 11/07/2011 16:17, Jérôme Loyet a écrit :
>>> Or else, with FPM, use one pool for all vhost, and define an
>>> open_basedir
>>> variable like with mod_php. Is that feasible ? Is it secure ?
>> it's feasible and secure as mod_php.
>
> But, I want use Apache Worker. Mod_php is not available in this mod.
>
> Le 11/07/2011 16:23, rainer@ultra-secure.de a écrit :
>> open_basedir kills the realpath_cache.
>> It's a negative performance impact :-(
>
> What to do then?


Move those who need the speed to a php-fpm only server (and charge more) ;-)

One can modify PHP to stop clearing the realpath_cache, but we never went
to production with that - we know too little about the inner workings of
PHP.

I think can give it a try even with 700 hosts, if you have a large swap space and large amount of RAM, it will go,
php-fpm processes will not consume that much, they are nicely swappable out of RAM, and they share good amount of memory between processes, dont forget about throwing away unnecessary extensions, it is real to get about 5 Mb per php-fpm fork in active state, and about 200-300 Kb when swapped out, so even without on-demand spawning, there will be 250 Kb * 750 hosts = 187.5 Mb of resident ram usage when everything is swapped out. And its still faster to load process from swap, than create new process.
And dont forget about php opcode cache, i`m not sure how often it will be resetted with 700 sites, but the most active site scripts will be cached, it will not only speed up execution twice, but lower amount of RAM required to process scripts, with Wordpress thats (as mentioned above) about 35 Megs and about 5 Megs when WP scripts are cached in EAccelerator, or XCache.
EAccelerator actually still can do "swapping" of compiled scripts to disk ( see disk cache settings for it ).

Good luck.

On 11 июл, 17:23, rai...@ultra-secure.de wrote:
> > I do not have any follow-up.
>
> > As I understand, today we can't, with the last stable version of FPM,
> > manage many websites on one server.
> > So, how to use php with apache worker ?
>
> > FastCGI ?
>
> > Or else, with FPM, use one pool for all vhost, and define an
> > open_basedir variable like with mod_php. Is that feasible ? Is it secure ?
>
> open_basedir kills the realpath_cache.
> It's a negative performance impact :-(

It needs to check if the folder fits the allowed path every time.
But it should be a small overhead comparably to 700 simultaneous
processes.
Do you have any figures to compare?
Is it CPU or IO-problem?

The bigger problem is that open_basedir gaps were disclosed
periodically and you need to keep updating PHP.

>What to do then?

There is no silver bullet :)
Try and compare, as usually.

>
> On 11 июл, 17:23, rai...@ultra-secure.de wrote:
>> > I do not have any follow-up.
>>
>> > As I understand, today we can't, with the last stable version of FPM,
>> > manage many websites on one server.
>> > So, how to use php with apache worker ?
>>
>> > FastCGI ?
>>
>> > Or else, with FPM, use one pool for all vhost, and define an
>> > open_basedir variable like with mod_php. Is that feasible ? Is it
>> secure ?
>>
>> open_basedir kills the realpath_cache.
>> It's a negative performance impact :-(
>
> It needs to check if the folder fits the allowed path every time.

We think we could get away with just disabling any kind of
symlink-functions (disable_functions=....)
AFAIK, it's only a problem when you could possibliy symlink out of the
open_basedir cage.
But we're amateurs, admittedly.
And as I've said, PHP (if you build it yourself) is difficult to stabilize
in itself. Thus, I've not put that change into production.


> But it should be a small overhead comparably to 700 simultaneous
> processes.
> Do you have any figures to compare?
> Is it CPU or IO-problem?

Sites with open_basedir disabled perform a bit better. It's not too much,
but it's noticeable even without watching the output of !YSlow...

> The bigger problem is that open_basedir gaps were disclosed
> periodically and you need to keep updating PHP.

As if you wouldn't need to do that anyway :-(

The last time I upgraded the AMP-stack on a server, it would ruin all
typo3-installations.
Some default changed and it messed up the UTF8/latin translation...