Re: [PHP] APC & FastCGI != upload progress ?

Hi David, sounds good.

It's over a year since we've used Apache/FastCGI, so it's a bit hazy!  
The main problem I remember is using Rails under FastCGI on Apache 2.0  
with something like:

	FastCgiServer /path/to/rails/public/dispatch.fcgi -initial-env  
RAILS_ENV=production -processes 2 -idle-timeout 120

If you have FastCGI processes started by the Apache process manager,  
you get some ruby processes that don't want to die when you do  
restarts, and in particular we used to get these sort of errors in the  
log (which I've somehow dug out, should be archiving more!):

> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27562)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27563)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27564)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27565)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27566)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27567)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27568)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27569)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27570)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27571)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27572)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27573)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27574)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27575)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27576)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27577)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27578)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27579)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27580)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27581)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27582)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27583)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27584)
> [Fri Mar 02 13:27:55 2007] [warn] long lost child came home! (pid  
> 27585)

As I recall that was on a graceful restart of Apache; hard restarts  
were OK but they're not too nice on a live site.

If I can find any more info from rooting around in logs I'll follow up.

Cheers,
Igor

On 4 Apr 2008, at 16:55, David Birnbaum wrote:

> Igor, others,
>
> It might be helpful if you could provide some specifics on what does  
> or doesn't work with Apache 2.2 so we can try to get it fixed in the  
> latest code.
>
> David.
>
> -----
>
> On Thu, 3 Apr 2008, Igor Clark wrote:
>
>> Hello Steve.
>>
>> I've found that the mod_fastcgi code and Apache 2.x aren't
>> particularly happy together, and there are process management issues.
>>
>> Conversely I run PHP as a FastCGI server in several production
>> environments with few or no problems and use APC on all of them with
>> no trouble.
>>
>> I've had PHP/FCGI communicating over TCP with Apache 2.2 &  
>> mod_fastcgi
>> but only in a test envrionment; the config is confusing and seems a
>> bit convoluted. There's some info at http://www.hilluzination.de/php-fastcgi/php-fastcgi.html#id2450887
>>
>> These days however we use http://nginx.net/ pretty exclusively, for a
>> number of reasons (including the performance gains over Apache),
>> notably that the configuration is significantly more readable and
>> seems to scale better than Apache's. The FastCGI support is also  
>> good.
>>
>> Cheers,
>> Igor
>>
>> On 30 Mar 2008, at 18:52, steve wrote:
>>
>>> Hmmm... I am working on a PHP daemon for comet style connections...
>>> I'll keep that idea in mind. I guess that using Flash is best  
>>> solution
>>> at the moment.. at least the only one I have working...
>>>
>>> I'm guessing that FastCGI is buffering the upload until complete.  
>>> PHP
>>> docs might want to document that.
>>>
>>> FastCGI is also breaking Apache's deflate module, but that is
>>> another issue...
>>>
>>> -s
>>>
>>> On Wed, Mar 26, 2008 at 6:35 PM, Jim Lucas <[email protected]> wrote:
>>>>
>>>> steve wrote:
>>>>> We can get upload progress to work with the APC extension for PHP
>>>>> 5.2.x only on machines that are not using FastCGI. (Apache2.2 if  
>>>>> it
>>>>> matters).
>>>>>
>>>>> Does anyone have a suggestion where to look?
>>>>>
>>>>> Will it even be possible?
>>>>>
>>>>> Thanks in advance,
>>>>> -s
>>>>>
>>>>
>>>> I built a work around.  It requires you to run a PHP daemon.  It
>>>> handles
>>>> the uploads and passes the information off how ever you want.  To a
>>>> DB,
>>>> to the filesystem.  Your choice.  From that information, you can
>>>> create
>>>> a progress meter.
>>>>
>>>> I haven't fleshed out all the bugs, but it seems to work like I
>>>> want it
>>>> too at least.
>>>>
>>>> Jim Lucas

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/