output_buffering in php.ini is determinative; it defaults to 4KB, though it cannot be set at runtime by ini_set()—it must be set directly in php.ini. Well placed flush()/ commands in display code can keep the user informed about how execution of a big script is proceeding.
IIS is another story altogether. It usually holds back screen output until script execution completes. A Microsoft engineer offered this lame explanation:
"For performance reasons and interoperability with some ASP.NET features ... we entirely buffer responses < 1MB and then send them at once."
In IIS 7.5, it's actually 4MB. A 30MB SQL script may take a minute or more to execute. Leaving the user uninformed for that long is rude, but IIS Manager offers no access to the controlling variable.
A recommended workaround for this bit of IIS stupidity is first, in the left panel of IIS Manager, create an IIS "web site" for you app, called, say, mysitename; second, in the central IIS Manager panel find the name of the PHP engine--say it's PHP52_via_FastCGI; then run this command ...
%windir%\system32\inetsrv\appcmd set config "mysitename" /section:handlers /commitPath:apphost -[name='PHP52_via_FastCGI'].ResponseBufferLimit:0substituting your values for
mysitename and PHP52_via_FastCGI. Then restart IIS.Last updated 20 Nov 2013
