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 mysitename and PHP52_via_FastCGI. Then restart IIS.