php - implicit_flush 的 "serious performance implications"是什么？

Question

我网站的管理部分有一堆非常慢的报告生成脚本，它们在生成时逐行echo 输出。要立即将此输出刷新到浏览器，而不是用户必须等待几分钟才能看到任何响应，我们有 output_buffering禁用，我们调用 ob_implicit_flush在此类脚本的开头。

为了方便起见，我考虑只打开 implicit_flush在 php.ini 中设置，而不是向每个将从中受益的脚本添加 ob_implicit_flush() 调用。

但是，该文档包含以下可怕但无法解释的评论:

implicit_flush

...

When using PHP within an web environment, turning this option on has serious performance implications and is generally recommended for debugging purposes only.

这些“严重的性能影响”是什么？它们是否证明了手册的建议？

Answer 1

这可能是手册所暗示的，也可能不是，但是打开 implicit_flush 或调用 ob_implicit_flush() 具有严重性能影响的一种情况是通过 mod_php 使用 PHP 和 Apache mod_deflate启用。

在此上下文中，flush() 调用能够通过 mod_deflate 将输出一直推送到浏览器。如果您有任何以小块回显大量数据的脚本，刷新每个 block 将削弱 mod_deflate 压缩输出的能力，很可能导致“压缩”形式大于原创内容。

作为一个极端的例子，考虑这个简单的脚本，它会输出一百万个随机数:

<?php
    header('Content-Type: text/plain');

    for ($i=0; $i < 1000000; $i++) { 
        echo rand();
        echo "\n";
    }
?>

在关闭 output_buffering 和 implicit_flush 的情况下(现在)，让我们在打开开发工具的情况下在 Chrome 中执行此操作:

注意大小/内容列；解压缩后的输出大小为 10.0MB，但由于 mod_deflate 的 gzip 压缩，整个响应被压缩到 4.8MB，大小大约减半。

现在使用 implicit_flush 设置为 On 的完全相同的脚本:

再一次，“解压缩”输出的大小为 10.0MB。不过，这次 HTTP 响应的大小为 28.6MB - mod_deflate 的“压缩”实际上使响应大小增加了三倍。

对我来说，这足以让我有足够的理由听从 PHP 手册关于离开 implicit_flush 配置选项 off 并且只使用 ob_implicit_flush() 的建议(或手动 flush() 调用)在实际服务于某个目的的上下文中。