|The internet wasn't designed to display results of long batch jobs (e.g., SQL scripts) in real time.
Browsers do their own output buffering; the programmer has no control over that, though FireFox lately seems a bit more sprightly in this regard than Google Chrome.
Under Apache, |
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:0
substituting your values for
PHP52_via_FastCGI. Then restart IIS.
Last updated 20 Nov 2013