httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hajo Locke <Hajo.Lo...@gmx.de>
Subject Re: [users@httpd] proxy_fcgi - force flush to client
Date Thu, 01 Feb 2018 12:20:53 GMT
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 
>> <mailto: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.
>>
>> Luca
>>

Thank you,
Hajo


Mime
View raw message