On Tue, Dec 8, 2009 at 10:57 AM, Stanislav Malyshev wrote:
> How real would be the case of 2 hosts in the same pool having same configs,
> but the same hosts in different pool having different configs?
I never though about that but I can tell you I use all my websites
under the same pool. I part
Hi!
Unless there is a "Pool" identifier added:
Host can be different for the same pool
Path can be different for the same pool
.user.ini's don't work for *every* ini option.
How real would be the case of 2 hosts in the same pool having same
configs, but the same hosts in different pool havin
> On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
>> Why would you need that given that we have host, path or .user.ini
>> support? Which has to be backported to FPM as far as I know.
> you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
> things the user can't or shouldn't
you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
things the user can't or shouldn't change themselves in .user.ini type
files or with things like htscanner (pre 5.3)
On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle
hi,
On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle wrote:
> - Per-pool php.ini file (should be easy)
Why would you need that given that we have host, path or .user.ini
support? Which has to be backported to FPM as far as I know.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.or
Le 8 décembre 2009 01:21, Christopher Jones
a écrit :
>
>
> Jérôme Loyet wrote:
>> Yes it could be this way ... but you do repeat the pattern ('pool2')
>> for each entry. There is about 30 lines for each workers ... no
>> imagine having a multiuser environment with 30 customers ... you have
>> 900
Jérôme Loyet wrote:
> Yes it could be this way ... but you do repeat the pattern ('pool2')
> for each entry. There is about 30 lines for each workers ... no
> imagine having a multiuser environment with 30 customers ... you have
> 900 times a useless repeated pattern ... gnurf
If there are defi
Le 8 décembre 2009 01:04, Michael Shadle a écrit :
> 2009/12/7 Jérôme Loyet :
>
> so you're saying each worker just has a worker.name prefixed
>
> worker.name = pool1
> worker.user = nobody
> worker.group = nogroup
> worker.static.max_children = 5
> worker.dynamic.max_children = 20
> worker.dynami
2009/12/7 Jérôme Loyet :
so you're saying each worker just has a worker.name prefixed
worker.name = pool1
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynami
Hi!
worker.name= default;
worker.listen.address = tcp:127.0.0.1:9000
worker.listen.backlog = -1
worker.listen.owner = nobody
worker.listen.group = nogroup
worker.listen.mode = 0666
worker.php_defineshort_open_tag = On
You could also do it as:
[WORKER=default]
listen.address = tcp:127.0.0.1:900
2009/12/7 Stanislav Malyshev :
> Hi!
>
>> As for #1 we are working on changing the config file syntax and the idea
>> was to make it use nginx style. I don't think it will fit in ini file format
>> as it needs arrays or some sort of n+1 group structure support/nested
>> options.
>
> Nesting can be
Hi!
As for #1 we are working on changing the config file syntax and the idea
was to make it use nginx style. I don't think it will fit in ini file
format as it needs arrays or some sort of n+1 group structure
support/nested options.
Nesting can be done by name, and .ini can do arrays. See he
The problem with running a static amount of processes is trying to
figure out the right number. Also it is not elastic in any fashion.
Shared hosts would love the elasticity as it will allow sites to flex
up and down as needed without giving each individual user more
processes than they rea
For #2 it might no longer be needed that might be up for debate. It's
nice to be able to override a single option. But 5.3 with it's
htaccess/htscanner behavior might work good enough for most things
(but PHP_INI_SYSTEM might be still nice to override one offs instead
of having to point to
Hi!
Couple of other notes here:
1. I understand this SAPI uses its own XML config format. While it is
not unheard of for SAPIs to integrate into external servers and thus
have diferent config ways, this one is self contained - so I wonder if
it would be possible to make it configured by .ini?
Correct. Biggest lacking feature.
While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run
more processes in given time period than started) - "stepping" back to how apache operates with its prefork mechanism (iirc there
Sent from my iPhone
On Dec 7, 2009, at 5:57 AM, Jérôme Loyet wrote:
2009/12/7 Reinis Rozitis :
- See if the normal libevent or libev could handle all the needs and
not a patched copy anymore (or get with the libevent team)
Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs
2009/12/7 Michael Shadle :
> On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
>> On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:
>>
>>> That's the thing I want to avoid, actually.
>>> Moving something out of PHP just because you're afraid of its release cycles
>>> means you make it hard
2009/12/7 Reinis Rozitis :
>> - See if the normal libevent or libev could handle all the needs and
>> not a patched copy anymore (or get with the libevent team)
>
> Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external
> libevent on system now.
there is no more patch libevent,
- See if the normal libevent or libev could handle all the needs and
not a patched copy anymore (or get with the libevent team)
Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external
libevent on system now.
- Adaptive process support (the major thing lacking)
Somewhat don
On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
> On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:
>
>> That's the thing I want to avoid, actually.
>> Moving something out of PHP just because you're afraid of its release cycles
>> means you make it harder to maintain, not easier.
>
> Ev
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:
> That's the thing I want to avoid, actually.
> Moving something out of PHP just because you're afraid of its release cycles
> means you make it harder to maintain, not easier.
Even if it is just the management component of it?
Any of the PHP
hi!
On Fri, Dec 4, 2009 at 10:18 PM, Stanislav Malyshev wrote:
> Hi!
>
>> You can check out its sources using the following command:
>> svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
>> php_5_3_fpm
>
> Just curious - any plans for win32 support?
I remember some discussions
On 07.12.2009 12:30, Jérôme Loyet wrote:
You can check out its sources using the following command:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
php_5_3_fpm
>
> Hi tony,
>
> I've been working on php-fpm. If I want to submit patches, what is the
> best way
2009/12/7 Antony Dovgal :
> On 05.12.2009 00:18, Stanislav Malyshev wrote:
>> Hi!
>>
>>> You can check out its sources using the following command:
>>> svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
>>> php_5_3_fpm
Hi tony,
I've been working on php-fpm. If I want to submit
On 05.12.2009 03:25, Michael Shadle wrote:
> "What if it was just a modification to the FCGI SAPI, and the FPM
> management features, config file parsing, all that were in a
> standalone daemon. That allows for a lot of changes and such to be
> done in the daemon portion without having to align it
On 05.12.2009 00:18, Stanislav Malyshev wrote:
> Hi!
>
>> You can check out its sources using the following command:
>> svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
>> php_5_3_fpm
>
> Just curious - any plans for win32 support?
If you want to work on it - sure, no probl
what version of PHP-FPM code is this based off of? the latest 0.6.x at
launchpad or one of the older patches?
we have had reports of some issues with php 5.3.x and php-fpm 0.6.x.
Andrei had changed the code from being a patch to being a standalone
daemon that builds against vanilla php sources for
Antony - thank you so much! This is quite a surprise though, I didn't
know there were plans for this... I was talking to gwynne on IRC about
the best way to get this going.
I suppose it being a separate SAPI works, but I had also thought:
"What if it was just a modification to the FCGI SAPI, and
Hi!
You can check out its sources using the following command:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
php_5_3_fpm
Just curious - any plans for win32 support?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN:
On 04.12.2009 16:58, Johannes Schlüter wrote:
> How big would be the impact in regards to BC and stuff for merging it
> back in 5_3? If i read the svn log correct it's just a SAPI ... so
> adding it might be low risk as it only affects people using it.
That's right, it's a separate SAPI, it doesn'
On Fri, 2009-12-04 at 15:53 +0300, Antony Dovgal wrote:
> Hello all.
>
> I'm glad to announce that we now have FPM SAPI available for testing in a
> separate SVN branch.
>
> You can check out its sources using the following command:
> svn co http://svn.php.net/repository/php/php-src/branches/PHP
On 04.12.2009 13:53, Antony Dovgal wrote:
> - advanced process management with graceful stop/start;
> - ability to start workers with different uid/gid/chroot/environment and
> different php.ini (replaces safe_mode);
> - stdout & stderr logging;
> - emergency restart in case of accidental opcode c
Hello all.
I'm glad to announce that we now have FPM SAPI available for testing in a
separate SVN branch.
You can check out its sources using the following command:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
php_5_3_fpm
Building FPM is as easy as `./configure --enabl
34 matches
Mail list logo
