httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hajo Locke <>
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 < 
>> <>>:
>>     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:
>>     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, 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,

View raw message