httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: [users@httpd] proxy_fcgi - force flush to client
Date Sat, 03 Mar 2018 16:02:47 GMT
2018-02-19 12:07 GMT+01:00 Hajo Locke <Hajo.Locke@gmx.de>:

> Hello,
>
>
> Am 19.02.2018 um 10:11 schrieb Hajo Locke:
>
> Hello,
>
> Am 08.02.2018 um 19:33 schrieb Luca Toscano:
>
>
>
> 2018-02-02 12:20 GMT+01:00 Hajo Locke <Hajo.Locke@gmx.de>:
>
>>
>>
>> Am 02.02.2018 um 07:05 schrieb Luca Toscano:
>>
>> Hello Hajo,
>>
>> 2018-02-01 13:20 GMT+01:00 Hajo Locke <Hajo.Locke@gmx.de>:
>>
>>> Hello Luca,
>>>
>>> Am 01.02.2018 um 09:10 schrieb Hajo Locke:
>>>
>>> Hello Luca,
>>>
>>> Am 01.02.2018 um 04:46 schrieb Luca Toscano:
>>>
>>> Hi Hajo,
>>>
>>> 2018-01-31 1:27 GMT-08:00 Hajo Locke <Hajo.Locke@gmx.de>:
>>>
>>>> Hello List,
>>>>
>>>> currently i compare features and behaviour of proxy_fcgi to classical
>>>> methods like mod_fastcgi/mod_php.
>>>>
>>>> mod_php/fastcgi have options to send every output from backend
>>>> immediately to client. So it is possible to see progressing output in
>>>> browser and not complete websiteoutput at once.
>>>>
>>>> Here is an example script:
>>>> https://pastebin.com/4drpgBMq
>>>>
>>>> if you ran this with php-cli or adjusted mod_php/mod_fastcgi you see
>>>> progress in browser and numbers 0 1 2 appear one after another.
>>>> If you run this with proxy_fcgi you will see no progress, but complete
>>>> output at once.
>>>>
>>>> mod_proxy knows about worker parameter flushpackets, but the docs say
>>>> this is in effect only for AJP. I can confirm that this and related options
>>>> have no effect.
>>>> There are some workarounds posted in the web, but only one worked for
>>>> me. If i add following line to the script, i also see a progress with
>>>> proxy_fcgi in browser:
>>>>
>>>> header('Content-Encoding: none');
>>>>
>>>> Somebody knows a working workaround which works without scriptediting?
>>>> some workarounds tell about using "SetEnv no-gzip 1". This was not working
>>>> for me and iam not please to disable content-compression.
>>>> Is it planned to support >>flushpackets<< also to proxy_fcgi?
>>>>
>>>> May be this is not important for typical website but some
>>>> service/monitoring scripts.
>>>>
>>>>
>>> The functionality is committed to trunk but never backported to 2.4.x
>>> because I was not sure about its importance, it looks like some users might
>>> benefit from it :)
>>>
>>> The trunk patch is http://svn.apache.org/r1802040, it should apply to
>>> 2.4.x if you want to test it and give me some feedback.
>>>
>>> Thanks!
>>>
>>> I tried this and it works great. I see same behaviour as expected with
>>> other methods. I think some users might benefit from this. I saw some
>>> discussion related to this topic and people just ended up by ungainly
>>> workaround.
>>> Great news!
>>>
>>> Unfortunately i spoke too soon. I was too euphoric when reading your
>>> answer ;)
>>> Behaviour is definitively more then expected, but it seems there is
>>> still a minimum-limit for the buffer to flush. I suppose this limit is 4096
>>> bytes.
>>> you can comprehend this with pastebinexample above.
>>> Change line 2 from "$string_length = 14096;" to "$string_length = 1331;"
>>> When calling this php-file you will see no progress. All output appears
>>> at once.
>>> Change scriptline to "$string_length = 1332;", you will see at least 2
>>> steps of output, because first step seems to break this 4096 bufferlimit.
>>> increasing $string_length more and more results in more steps of output.
>>> So current mod_proxy_fcgi.c from svn with configured "flushpackets=On"
>>> seems to work exaktly like "flushpackets=auto iobuffersize=4096".
>>> setting iobuffersize to lower numbers has no effect.
>>> What do you think? Is there still a hard-coded limit or do i have a
>>> problem in my configuration?
>>> I would be really glad, if you could take a look at this issue.
>>>
>>
>> I am far from being an expert in PHP, but I added "ob_flush();" right
>> before "flush()" in your script and the 1331 use case seems flushing
>> correctly. Do you mind to check and let me know what do you get on your
>> testing environment? As far as I can see in the mod_proxy_fcgi's code the
>> iobuffersize variable is taken into account..
>>
>> It seems that i was additional mocked by my browser. There is no need to
>> edit this script, just using the right browser ;)
>> I think your new mod_proxy_fcgi.c did it and my testing was incorrect. I
>> think we can go into weekend..
>>
>
>
> Full list of commits is: svn merge -c 1802040,1807876,1808014,1805490
> ^/httpd/httpd/trunk .
>
> mod_proxy_fcgi.c only patch: http://people.apache.
> org/~elukey/httpd_2.4.x-mod_proxy_fcgi-force_flush.patch
>
> If you want to give it another round of test it would be really
> appreciated, in case everything is fine I'll propose it for backport to
> 2.4.x :)
>
> sorry for late reply, was in the clinch with special kind of the flu and
> still not over.
> i applied patch to current 2.4.29 sources and can confirm it works, but
> there is a little constraint.
> It only works, when using ob_flush() in script:
> https://pastebin.com/DVFzCBAc
> with mod_php or classical mod_fastcgi it works in script by just using
> flush(). so in example script lines 3,7,17 are not necessary
> Is this proxy dependent?
>
> it is working now. did some changes to php-configuration and dont see any
> differences any more. httpd_2.4.x-mod_proxy_fcgi-force_flush.patch
> <http://people.apache.org/%7Eelukey/httpd_2.4.x-mod_proxy_fcgi-force_flush.patch>
> is working.
> Thanks Luca. From my side i would be happy to have this patch in next
> official release.
>

Change accepted, it will be part of 2.4.31 :)

Luca

Mime
View raw message