Hi,

With Andrei not working on the project anymore I'm considering moving back
to using spawn-fcgi. The new patches are barely tested (it compiles so it's
fine doesn't cut it) and I assume no one is actually working on the code.

Is there a disadvantage for me if I were to head back to using spawn-fcgi
(Speed, stablility)?

--
Kind Regards,
Mathew Davies

On Sat, Jul 4, 2009 at 9:33 PM, Mathew
Davies<thepixeldeveloper@googlemail.com> wrote:
> Hi,
>
> With Andrei not working on the project anymore I'm considering moving back
> to using spawn-fcgi. The new patches are barely tested (it compiles so it's
> fine doesn't cut it) and I assume no one is actually working on the code.
>
> Is there a disadvantage for me if I were to head back to using spawn-fcgi
> (Speed, stablility)?
>

you need process manager (supervisord/god/runit/daemontools) if you
want to use spawn-fcgi (except for supervisord which can manage and
spawn fastcgi processes)


--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

You can also use php-cgi -b $port with a combination of sudo and such
and the right environment variables.

That's what I was doing using ubuntu's upstart. Any supervisor should
be able to do the same. I don't see any benefits from using spawn-fcgi
since you still have to manage all the pools independently.

What would give you more confidence in the project? Obviously the
first step is compiling but we do have a lot of people using those
patches (we should figure out some sort of metrics system so we know)
- I am using 5.2.10 myself without any issues (except my caching issue
which is only on a couple machines and probably due to something else
it's been around even with andrei's last patch I believe)

I'm open for ideas on how to ensure things are "working" - even andrei
himself could release a buggy version and would have to release a
fixed patch for it. Only so much we can do.

I'm open for ideas - perhaps a survey to try to determine how many
people are using php-fpm, what version, what platforms, etc. I could
actually whip up a script to report peoples php configuration so we
get ideas of it all and make it easy to auto submit a phpinfo() or
something.

Sent from my iPhone

On Jul 4, 2009, at 8:43 AM, Edho P Arief <edhoprima@gmail.com> wrote:

>
> On Sat, Jul 4, 2009 at 9:33 PM, Mathew
> Davies<thepixeldeveloper@googlemail.com> wrote:
>> Hi,
>>
>> With Andrei not working on the project anymore I'm considering
>> moving back
>> to using spawn-fcgi. The new patches are barely tested (it compiles
>> so it's
>> fine doesn't cut it) and I assume no one is actually working on the
>> code.
>>
>> Is there a disadvantage for me if I were to head back to using
>> spawn-fcgi
>> (Speed, stablility)?
>>
>
> you need process manager (supervisord/god/runit/daemontools) if you
> want to use spawn-fcgi (except for supervisord which can manage and
> spawn fastcgi processes)
>
>
> --
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

>
> What would give you more confidence in the project?
>

I think we need a continuous build procedure so when the latest version is
built, unit tests are ran and the results reported back. We also need
someone who can understand the code, because if a serious flaw shows up (it
can happen). Who's going to fix it? It'd be the end of PHP-FPM. Also, I
think we should push really hard to get this into PHP, but I'm not sure how
to do this. Suggestions?

Yes, please setup a survey, it's the first step to getting some reports
going. With this we could spot bugs much easier, ex : Does this extension
affect PHP-FPM, etc ... Something is better than nothing right?

2009/7/4 Michael Shadle

>
> You can also use php-cgi -b $port with a combination of sudo and such and
> the right environment variables.
>
> That's what I was doing using ubuntu's upstart. Any supervisor should be
> able to do the same. I don't see any benefits from using spawn-fcgi since
> you still have to manage all the pools independently.
>
> What would give you more confidence in the project? Obviously the first
> step is compiling but we do have a lot of people using those patches (we
> should figure out some sort of metrics system so we know) - I am using
> 5.2.10 myself without any issues (except my caching issue which is only on a
> couple machines and probably due to something else it's been around even
> with andrei's last patch I believe)
>
> I'm open for ideas on how to ensure things are "working" - even andrei
> himself could release a buggy version and would have to release a fixed
> patch for it. Only so much we can do.
>
> I'm open for ideas - perhaps a survey to try to determine how many people
> are using php-fpm, what version, what platforms, etc. I could actually whip
> up a script to report peoples php configuration so we get ideas of it all
> and make it easy to auto submit a phpinfo() or something.
>
> Sent from my iPhone
>
>
> On Jul 4, 2009, at 8:43 AM, Edho P Arief wrote:
>
>
>> On Sat, Jul 4, 2009 at 9:33 PM, Mathew
>> Davies wrote:
>>
>>> Hi,
>>>
>>> With Andrei not working on the project anymore I'm considering moving
>>> back
>>> to using spawn-fcgi. The new patches are barely tested (it compiles so
>>> it's
>>> fine doesn't cut it) and I assume no one is actually working on the code.
>>>
>>> Is there a disadvantage for me if I were to head back to using spawn-fcgi
>>> (Speed, stablility)?
>>>
>>>
>> you need process manager (supervisord/god/runit/daemontools) if you
>> want to use spawn-fcgi (except for supervisord which can manage and
>> spawn fastcgi processes)
>>
>>
>> --
>> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>>
>


--
Kind Regards,
Mathew Davies

On Sat, Jul 4, 2009 at 12:31 PM, Mathew
Davies<thepixeldeveloper@googlemail.com> wrote:

> I think we need a continuous build procedure so when the latest version is
> built, unit tests are ran and the results reported back. We also need
> someone who can understand the code, because if a serious flaw shows up (it
> can happen). Who's going to fix it? It'd be the end of PHP-FPM. Also, I
> think we should push really hard to get this into PHP, but I'm not sure how
> to do this. Suggestions?

I've already got 4-5 PHP/PECL developers on the hook. Right now I'm
waiting to hear back from them on their recommendations for next
steps. So getting it into PHP or at least into PECL is already being
worked on.

Continuous builds would be great, I'm just trying to determine how
test cases can be written.

And yes, someone who understands the internals would be great. That's
the great part of open source though, everyone can contribute, read,
fix, etc.

> Yes, please setup a survey, it's the first step to getting some reports
> going. With this we could spot bugs much easier, ex : Does this extension
> affect PHP-FPM, etc ... Something is better than nothing right?

Correct.