Hi Rüdiger, 2017-07-10 8:31 GMT+02:00 Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com>:
> > > > > *Von:* Luca Toscano [mailto:toscano.l...@gmail.com] > *Gesendet:* Samstag, 8. Juli 2017 09:52 > *An:* Apache HTTP Server Development List <dev@httpd.apache.org> > *Betreff:* Re: mod_proxy_fcgi and flush > > > > Hi Jacob, Helmut! > > > > 2017-07-06 20:54 GMT+02:00 Jacob Champion <champio...@gmail.com>: > > On 07/06/2017 11:13 AM, Jim Jagielski wrote: > > works 4 me... > > > Doesn't for me. E.g. with a script like > > <?php > print("hi!\n") > flush(); > sleep(1); > print("hi!\n"); > ?> > > it takes 1 second to receive a single chunk with both lines in it. > > From a quick skim I assume this is because we don't use nonblocking > sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi > that says, "Yes it sucks to [get the actual data] in a second recv call, > this will eventually change when we move to real nonblocking recv calls.") > > > > Quick check from my side too, so not sure if it makes sense. IIUC the > comment is about getting all the headers from the FCGI backend > (get_data_full(..., AP_FCGI_HEADER_LEN)), then get the response body in > another one (the [actual data]). > > > > I checked mod_fcgi as Helmut suggested and it seems to me that the -flush > feature is a simple "flush every data that you receive", so I tested the > following patch with Jacob's php example code and it seems doing what > Helmut asked (please correct me if I am wrong). > > > > Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config > file. > > > > http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_ > fcgi-force_flush.patch > > > > Flushing unconditionally is a bad idea performance wise. Please have a > look how ajp solved this issue: > > > > https://svn.apache.org/r327185 > > https://svn.apache.org/r384580 > > https://svn.apache.org/r390210 > > https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ > proxy/mod_proxy_ajp.c?r1=325879&r2=390210 > > > > Hint: The above diff contains further unrelated changes. > > > Definitely, I added that quick and dirty patch to show my idea, really far from being ready for a commit :) Will review the commits that you posted, thanks! Luca
